01AND
Applied AI development.
Custom AI systems for problems a prompt and an API key won't solve: retrieval, agents, document extraction, and the eval harnesses that tell you whether any of it actually works.
Logic Gate Labs is a small engineering studio. We build AI software and the infrastructure under it: retrieval, agents, ML pipelines, and the backends they run on. Most of it ships in Elixir, Rust, and Postgres.
Most projects land in one of these three areas. The specifics depend on your problem, so the best place to start is a short conversation.
Custom AI systems for problems a prompt and an API key won't solve: retrieval, agents, document extraction, and the eval harnesses that tell you whether any of it actually works.
Making slow or expensive workloads faster and cheaper. We profile first, then fix whatever the numbers point at, whether that's a query, batching, the model, or the architecture.
Getting models into existing systems with old data, strict SLAs, or regulators in the picture. It's mostly plumbing, and the plumbing is usually where these projects succeed or fail.
Nine things we've built. Some are in production and some are early, and each one says which.
Pricing and forward modeling for secondaries investments at a global private equity firm, replacing the Excel models the team used to run.
Secondaries pricing lived in spreadsheets. With each deal in its own workbook, it was hard to compare positions, see how an estimate changed over time, or look back at what the numbers said when a decision was made.
A TypeScript application on AWS prices secondaries positions and models how they're likely to play out, with AI doing work that used to be hand-built formulas. Investment decisions are recorded in the same system, next to the pricing and projections they were based on.
Legal cases turn on chains of events (grievance, response, appeal, exhaustion), and similarity search can't follow a chain. So Trace stores each case as a graph.
Section 1983 prisoner civil-rights cases depend on relationships and timelines. Generic RAG returns passages that are about the question instead of the actual sequence of events, and a lawyer can't use an answer they can't trace back to a page.
The monorepo separates model selection, a multi-provider LLM gateway, a partitioned knowledge store, and the Phoenix app. An LLM intake pipeline turns documents into deduplicated graph nodes and edges. At query time, a context layer combines vector search with one-hop graph expansion, trims the result to a character budget, and hands it to an agent with seven tools.
Three indexes over one corpus (document structure, embeddings, and an entity graph) combined into one cited answer, or a refusal when the sources don't support one.
Frontier models reason well but know nothing about your documents. Basic RAG chunks blindly and takes the top-k by cosine similarity, which throws away document structure, cross-references, and entities that span the corpus. The model ends up working from disconnected fragments.
Intext keeps a per-document nested-set tree and leaf-level HNSW vectors in the same table, so one SQL statement handles both the vector search and the small-to-big expansion. A corpus-wide knowledge graph links entities by deterministic key. Retrieval merges vector and lexical results with reciprocal-rank fusion, and every answer has to cite passages that resolve back to the source.
You file a task, an agent works on it in an isolated VM inside your own cloud account, and you get back a pull request to review.
Background coding agents run untrusted, model-generated changes. That code needs somewhere safe, auditable, and cost-tracked to run, ideally in the customer's own VPC instead of a vendor's.
One Elixir umbrella builds three releases (control plane, runner, and in-VM supervisor) and picks one at boot. Runners connect outbound over WebSockets and never accept inbound connections, so a runner can live entirely inside a customer's GCP project. Each task gets a fresh VM whose supervisor connects back over a Phoenix Channel and streams execution. Git credentials are never passed on the command line.
Endpoint protection where every model runs on the machine itself. No cloud calls, and no telemetry leaves the host.
Most EDR products send process, file, and network telemetry to a cloud backend to classify it. Riggs runs its models locally instead, so it works offline and endpoint data stays on the machine.
Platform sensors feed a normalizer that emits OCSF-style events into a staged pipeline: threat-intel bloom-filter lookups, a static model over 256-float Mach-O/ELF feature vectors, YARA-X rules, and a behavioral stage. A weighted merger combines their scores, and a high-severity verdict is never averaged away by lower ones. Current status: the ONNX stages fall back to heuristics for now, while the merger, rules, and DLP paths are live and tested.
A model reads every receipt, and a confidence gate decides which ones a person needs to look at.
A firm with around 2,000 clients gets buried in receipts, invoices, and statements that all need to become correctly categorized ledger entries. Plain LLM extraction isn't accurate or auditable enough when tax liability is involved, and a model's own confidence score isn't worth much.
An Oban pipeline runs extract, reconcile, classify, route, and notify stages. It tries a cheap model first and escalates when needed, all behind one provider behaviour. Confidence comes from real signals (beta-smoothed vendor priors, label entropy from logprobs, structural features), and routing weighs materiality against ambiguity. Only the uncertain items go to a keyboard-driven review console or a magic-link client portal.
Proper route optimization, constraints and all, built into a live dispatch board that a twelve-tech trades shop can afford.
Small trades shops get drag-and-drop calendars. Real scheduling has usually meant a proprietary solver and a consultant billing $250 an hour. Open-source solvers and LLMs make it possible to offer at small-business prices.
A Python sidecar solves each shop-day as an arc-based VRPTW mixed-integer program in OR-Tools, behind a typed HTTP contract. The app works out hard feasibility itself and passes only the allowed (tech, job) pairs, so the solver never sees an illegal assignment. Every solution is re-validated in Elixir and only used if it beats an in-BEAM greedy heuristic, so the board keeps working if the sidecar goes down.
A reading and notes system you own outright, with the feed ranked by a single SQL query.
Useful reading ends up spread across feeds, browser tabs, and Evernote, often on services that can shut down. Feeds pile up, and clipping works differently in every browser.
Phoenix LiveView runs the reader, vault, and search, and Oban schedules fetching, embedding, tagging, and pruning. Articles are embedded inside the BEAM with Bumblebee and stored in pgvector. The "For You" feed is ranked entirely in Postgres using cosine distance to learned interest centroids, a penalty for disliked items, recency decay, and a slice reserved for exploration. Claude, under a spending cap, labels the links between closely related notes.
tmux for AI coding agents. Run a dozen of them and see at a glance which one needs you.
With a dozen terminal agents running, every window is a black box and nothing tells you which one is waiting on you. Permission prompts sit unanswered while detached agents keep going.
A background daemon owns every PTY and runs a vt100 parser per pane for scrollback and screen classification. Each agent has a state machine (Unknown → Working ⇄ Blocked → Done → Idle) in a core crate with no I/O. The versioned wire protocol sends length-prefixed frames with server-computed screen diffs, batched to about 16 ms. Anything you can do in the TUI is also a CLI command over the Unix socket.
Logic Gate Labs builds AI software that has to hold up in production. Most of our time goes into the parts around the model: retrieval, data pipelines, evaluation, cost controls, and the infrastructure it all runs on.
We mostly work in Elixir, Rust, and Postgres, and use other tools when a problem calls for them. We write the code ourselves, and we'd rather show you something running than hand you a strategy deck.
Projects usually start with three questions: what's the workload, what's it worth to you, and how much can it cost to run? The answers tend to settle the architecture and the choice of model.
We like the unglamorous side of AI: the parts that need to keep working at 3am when nobody's watching.
A few paragraphs about the problem is plenty. Rough ideas are fine.
If something is too slow, too expensive, or just doesn't fit off-the-shelf tools, tell us about it at info@logicgatelabs.com.