Application: agentic systems that hold when the answer has to be right.

Why Oxford Dynamics, why me

I have spent two years shipping agents that do a job in production: a research agent that drafts a daily briefing from 4.7M items with a human approving every issue, running as a LangGraph service with Postgres checkpoints and LangSmith traces; an open-source MCP server other people install (603 stars, 18.8k installs a month); a marketplace's admin surface that its founders query from Claude. At Pfizer, seven years leading platform engineering, a regulated environment: 1000+ sites, 500M+ events at peak, 99.9% uptime.

Straight answers. LangGraph and LangSmith are in production for me since September 2026. MCP is daily work, four servers shipped; A2A I have shipped as an agent card and a message endpoint. I self-host by default: 28 apps on one server, and a self-hosted RAG stack at Pfizer. AWS certified twice. I do not hold security clearance. Harwell two days a week from Folkestone works.

Four habits I would bring on day one

Agentic systems fail in the same places whoever builds them. These are the four things I do on every agent I ship, with the receipt for each.

1. Evals before features, from real inputs. Accuracy, latency and cost as numbers in CI before any model debate. For coolify-mcp I shipped a tool-selection eval suite with an injection and red-team pass; for Bellwether the critic and prose-gate nodes fail a draft that cannot cite its claims.
2. A named human in the loop, as a graph node. Nothing Bellwether publishes goes out without a person approving it, and that approval is a LangGraph interrupt with Postgres checkpoints, so a killed run resumes at the review step rather than restarting. Who approved what, when, on which draft, is a record and not a policy.
3. Every claim traceable to its retrieval. Researcher, writer and checker are separate nodes, the writer may not invent a number, and citations sit beside each claim for the approver. When the decision is high-stakes, the trace is the product.
4. Typed tool boundaries, so the model can change. Customer systems belong behind typed MCP tools with auth from the first deploy, so a model swap (or a move to a model that runs on the customer's own hardware) does not touch the integrations. Four MCP servers shipped, one with outside contributors and OAuth 2.1.

The numbers, with sources

Operating numbers, last 30 days, generated 2026-09-26. Sources per tile in profile.json; hover a tile for its source.