Agent engineering
Agents are easy to demo
and hard to put into production.
We build the unglamorous layer that decides which one you get: the MCP servers
that expose your systems safely, the plumbing that connects them to the models,
and the evaluation harness that tells you when a change made things worse.
Small team. We take a handful of engagements at a time and write the code ourselves.
01
MCP servers
We wrap the system you actually run — a warehouse, a ledger, an internal
API with fourteen years of history — in a Model Context Protocol server an
agent can use without being handed your database.
- Tools scoped to real operations, not a generic
run_sql escape hatch
- Per-caller authorisation, so the agent inherits a role rather than root
- Idempotency on every write, because a retried tool call is a duplicate order
- Structured errors an agent can recover from instead of a stack trace
02
MCP linking
One server is a demo. The value shows up when eight of them are reachable
from one conversation, with a single identity, an audit trail, and a
sensible answer to "what happens when the third one is down".
- A gateway across your servers with one auth model, not eight
- Tool namespacing and disambiguation before the model has to guess
- Rate limits, timeouts and circuit breaking at the boundary
- Every tool call logged with who asked, what ran, what came back
03
Agentic chat
Chat products where the conversation does work: reads your systems, drafts
the change, shows what it is about to do, and waits to be told to proceed.
Streaming, tool use, interruption, and state that survives a refresh.
- Human approval on anything that writes, spends or sends
- Resumable runs — a dropped connection is not a lost task
- Citations back to the source record, so an answer can be checked
- Cost and latency visible per conversation, not per month
04
Evaluation & observability
The part most teams skip and then regret. Without it, "the agent got worse
after Tuesday" is an argument rather than a measurement.
- Graded test sets built from your real transcripts
- Regression runs in CI, so a prompt change is reviewable like code
- Traces that show the tool calls, not just the final answer
- Honest failure taxonomies — what breaks, how often, and at what cost
Work
Client engagements are mostly under NDA, so here is a portfolio we built and
can show you every line of. Three complete products, three different problem
shapes, one engineering standard.
Applied product engineering
Orrery
CRM
Accounts orbit. Deals move along machined tracks.
A sales system built around the two questions a CRM usually answers badly:
what is actually happening on this account, and which of these deals is
quietly dying. Five signature screens, including a radial account graph and
a dependency-aware pipeline.
- API tests
- 1,216
- Endpoints
- 111
- Stack
- Next.js 16 · FastAPI · Postgres
Bramble
Marketplace
Goods you forage, not goods you're sold.
A storefront for independent makers, built around discovery rather than a
funnel. Guest checkout by default, stock held from the moment something
enters a basket, and money as integer minor units end to end.
- Tests
- 524 API · 1,040 web
- Endpoints
- 91
- Stack
- Next.js 16 · FastAPI · Postgres
Cairn
Offline-first
Stack the work. Mark the trail.
A productivity app across web, iOS and macOS, where every client holds a
replica and reconciles through a change feed. The hard part is not the UI —
it is that two devices editing offline have to converge, and be provably
right about it.
- Sync operations
- 51 of 51 bound
- Form factors
- Web · iOS · macOS
- Stack
- Swift 6 · GRDB · FastAPI
Agentic systems in progress
MCP server suite
Soon
Production-shaped reference servers for the systems people actually ask us
about first — Postgres, object storage, ticketing, internal HTTP APIs —
with the authorisation and idempotency work already done.
MCP gateway
Soon
One endpoint in front of many MCP servers: single sign-on, tool namespacing,
per-tool rate limits, and an audit log that a compliance team will accept.
Agent evaluation harness
Soon
Graded suites that run in CI against real transcripts, so changing a prompt
is a reviewable diff with a measured effect rather than a vibe.
Agentic chat starter
Soon
The chat surface we keep rebuilding: streaming, tool use, approval gates,
resumable runs and cost accounting — as something you can fork.
We read the pixels, not the build
A green pipeline says the code compiled. It does not say the screen is
right. On the portfolio below, opening each screen and looking at it found
a collection called "Under ₹1,500" holding a ₹6,200 platter, a header
reporting a query's LIMIT as if it were a total, and every
product link on a storefront pointing at a route nobody built. Every one of
those passed CI.
A test nobody has seen fail is not evidence
When we write a test for something that matters, we break the code on
purpose and check the test goes red. It is a cheap habit that catches the
assertion which was quietly comparing two error responses and passing.
Comments say why, not what
Code explains itself. What it cannot explain is the failure a line prevents.
Our comments name the bug that would exist without them, which is the thing
the next person actually needs.
We tell you what we did not do
Every handover lists what is unfinished, unverified or deliberately skipped.
A report that claims everything works is not a report, and you will find out
which parts were fiction at the worst possible moment.
The Model Context Protocol is a standard way for a model to discover and call
tools. Anthropic published it in November 2024 and handed it to the
Agentic AI Foundation under the Linux Foundation in December
2025, with OpenAI and Block as co-founders and AWS, Google, Microsoft,
Cloudflare and Bloomberg among the backers. That governance change is the
reason it is worth building on: it is no longer one vendor's protocol.
Adoption followed quickly — SDK downloads passed 97 million a month by early
2026, and roughly a quarter of the Fortune 500 have MCP servers running
somewhere. Which is also the problem. A great many of those servers are a
thin wrapper over an admin API with no authorisation model, and they work
beautifully until an agent does something nobody scoped.
The interesting work is not writing the server. It is deciding what a tool
should be, what it must refuse, and how the agent finds out it was refused.
That is where we spend our time.