Skip to content
Peak MindsTechnology & AI Studio

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.

What we build

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

Selected work

Systems we’ve built.

Five systems, each labelled with what it actually is. One is live; three are working prototypes; one is a design.

BuiltInfrastructure2026

AgentCost

AI Cost Observability Infrastructure

Teams adopt LLM agents and lose the thread between an invoice and the code that produced it. AgentCost instruments the client libraries an application already uses, captures token and cost data at the call site, and attributes every event to the agent, workflow, step and tool it came from. Instrumentation is two lines of Python; the rest happens transparently on a non-blocking path.

Pipeline stages
9
Capabilities built
8/8
Decisions logged
4
  • Python
  • FastAPI
  • PostgreSQL
  • SDK Design
  • LLM Observability
  • Next.js
How we think

Understand it before you build it.

Four steps, in order. Most of the failures we've seen come from skipping the first.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Technical landscape

The stack behind the work.

Everything here sits behind a project in the section above.

L57

Systems & Tooling

  • SDK Design
  • Observability
  • ChromaDB
  • Ollama
  • Prisma
  • Turborepo
  • Git
L47

Frontend

  • React
  • Next.js
  • TypeScript
  • Tailwind CSS
  • Vite
  • Design Systems
  • Accessibility
L37

Data & ML

  • NumPy
  • Pandas
  • scikit-learn
  • Time-Series Analysis
  • Geospatial Analysis
  • Statistics
  • Machine Learning
L29

Backend & Infrastructure

  • Python
  • FastAPI
  • Node.js
  • Express
  • REST APIs
  • PostgreSQL
  • Redis
  • BullMQ
  • Docker
L18

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.

Research & exploration

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.