We build systems that think, and the infrastructure that keeps them honest.
What that means
Applications where a language model is load-bearing — retrieval, structured extraction, agent-style control flow. Built so that when the model is wrong, the system still behaves.
What that takes
The layer underneath: SDKs, instrumentation and observability that show what a system is actually doing and what it costs. Including saying plainly what is built, what is a prototype, and what is still only a design.
Five practices, one way of working.
Each one has a project behind it. The work below shows what they look like in a running system.
- Retrieval pipelines: chunking, embeddings, vector stores, scoped search
- Schema-constrained extraction over unstructured language
- Local and hosted model inference, including streamed generation
- Human-in-the-loop routing where confidence isn't sufficient to commit
Systems we’ve built.
Five systems, each labelled with what it actually is. One is live; three are working prototypes; one is a design.
Understand it before you build it.
Four steps, in order. Most of the failures we've seen come from skipping the first.
01
Understand the system
Start with the actual problem rather than the requested feature. Where does information come from, what shape is it in, and where does the current process break? Most bad architecture is a correct answer to a question nobody checked.
02
Design the architecture
Decide the boundaries, the data flow and the failure modes before any interface exists. Write down the tradeoffs being accepted. A decision without a stated cost is usually a decision that hasn't been made.
03
Build the core
Build the part that carries the actual risk first. A prototype that skips the hard problem proves nothing, however complete it looks.
04
Iterate on evidence
Measure, observe, and let the result change the design. When something can't be measured yet, say so rather than asserting it works.
The stack behind the work.
Everything here sits behind a project in the section above.
Systems & Tooling
- SDK Design
- Observability
- ChromaDB
- Ollama
- Prisma
- Turborepo
- Git
Frontend
- React
- Next.js
- TypeScript
- Tailwind CSS
- Vite
- Design Systems
- Accessibility
Data & ML
- NumPy
- Pandas
- scikit-learn
- Time-Series Analysis
- Geospatial Analysis
- Statistics
- Machine Learning
Backend & Infrastructure
- Python
- FastAPI
- Node.js
- Express
- REST APIs
- PostgreSQL
- Redis
- BullMQ
- Docker
AI & Intelligence
- LLM Systems
- RAG
- Embeddings
- Vector Search
- Agents
- Structured Extraction
- Prompt & Context Design
- AI Evaluation
38 technologiesEvery one of these sits behind something in the work above.
Questions we haven’t answered yet.
Investigations currently open. Some become projects. Some turn out to be dead ends.
Reliable AI systems
What it takes for a system built on a probabilistic component to fail in ways that are contained and visible rather than silent.
AI infrastructure & observability
Measuring what these systems actually do in production — cost, usage, and where the work goes.
Evaluation
Deciding whether a change made a system better, on evidence rather than impression.
Agents & control flow
How autonomy should be bounded, and where a person has to stay in the loop for the design to hold.
Currently in the lab
All entries- BuildingInfrastructureJun 2026
Attributing cost through nested agent runs
When an agent calls a tool that calls another model, spend belongs to a tree rather than a flat list of API calls. Working through how scope should nest, what happens when a run is abandoned partway, and how attribution survives a single event loop interleaving many runs.
- TestingEvaluationMay 2026
How much of RAG quality is decided at chunk time
Most weak answers in a retrieval system trace back to retrieval, not generation. Comparing fixed-size, overlapping and structure-aware splitting on the same corpus and question set, to see how much of the gap a better prompt can actually recover. Early impression is: much less than expected.
- ExploringAI SystemsApr 2026
Can an extraction model be trusted to say it's unsure?
Human-in-the-loop systems route on confidence, so a miscalibrated confidence signal quietly breaks the entire safety argument. Looking at whether self-reported certainty, output-distribution signals or agreement across samples give a threshold worth routing on.
Have a difficult problem worth building?
We’re interested in ambitious software, AI systems, research collaborations and real problems where careful engineering actually changes the outcome.