# Chris Chabot

Canonical URL: https://chabot.dev/

Chris Chabot, Member of Technical Staff, building agent platforms

I design and build the systems that take agents from demonstration to infrastructure: runtime and orchestration, SDK contracts, memory and permissioning, and the evaluation and verification that decide what ships.

## Porting an agent by making omissions visible

A production coding agent of about 340,000 lines of Python, built by my colleagues, moved to TypeScript with one requirement: byte-identical behaviour in everything not specific to the new platform. I designed the method and directed the agents: a formal model, a checklist generated from the syntax tree, clean-context review, then replay.

- [Porting an agent by making omissions visible](https://chabot.dev/blog/porting-an-agent-by-making-omissions-visible/): How a checklist generated from the syntax tree, clean-context reviewers and a ledger that keeps “translated” apart from “reviewed” exposed what a model-assisted port of a 340,000-line Python agent had left out.
- [Comparing an agent’s context without copying the expected answer](https://chabot.dev/blog/comparing-an-agents-context-without-copying-the-expected-answer/): What it takes to show a port builds the same model request: rebuilding each part from independently captured inputs, labelling copied parts as supplied, and reading zero differences beside zero complete requests.
- [Replaying the deterministic part of an agent](https://chabot.dev/blog/replaying-the-deterministic-part-of-an-agent/): Recorded model replies and terminal output drove a port through whole sessions, so each difference could be located, classified and rechecked from a checkpoint. What the loop found, how its masks stayed honest and where live runs fit.

## Testing a release without turning every release into a research project

Release qualification for an agent-native cloud platform, designed around what a customer actually does. Evidence comes in layers, from a certified core to real browser journeys through sample apps, and a result is reused only where it still applies.

- [Testing a release without turning every release into a research project](https://chabot.dev/blog/testing-a-release-without-a-research-project/): How a release on an agent-operated platform stays finite: scope chosen once, evidence reused only where it still applies, limits on retries, and a plain record of what never got checked.
- [The test passed, but the person still could not do the thing](https://chabot.dev/blog/the-test-passed-but-the-person-could-not/): What a browser test has to establish beyond a 200 or a successful click, followed along a new user’s path from documentation to clipboard to the app and its dashboard.
- [Testing the promises an API actually makes](https://chabot.dev/blog/testing-the-promises-an-api-actually-makes/): How to test what a multi-service JSON-RPC API promises: coverage from its advertised methods, hostile payloads, concurrent writes and literal replay checks.

## What should be identical in a five-language agent SDK

Five languages have no single implementation to share, so the contract had to be data: fixtures for wire shapes, error codes and verified identity that the SDKs' own tests read.

- [What should be identical in a five-language agent SDK](https://chabot.dev/blog/what-should-be-identical-in-a-five-language-agent-sdk/): Which parts of a multi-language SDK must match exactly, such as errors, identity and event order, how shared fixtures enforce them, and what each language keeps.
- [Shipping an SDK that does not depend on the developer’s laptop](https://chabot.dev/blog/shipping-an-sdk-without-the-developers-laptop/): What has to be true before a private source tree can become a usable public SDK: fresh snapshots, a private manifest, a checker that never runs exported code, clean-container consumers and generated notices.
- [One application definition, several ways for an agent to use it](https://chabot.dev/blog/one-application-definition-several-agent-routes/): Generating discovery files, OpenAPI and MCP tools from one declared surface keeps the formats agreeing. It can't make a flag true, write a recovery procedure or count as extra test coverage. A skills pilot and a live byte comparison show where the line falls.

## Did your agent experiment test what you think it tested?

Before asking whether a change helped an agent, I want to know whether the comparison actually contains the change. The tooling here treats each run's configuration as a claim to be checked, and keeps corrections beside the original record rather than over it.

- [Did your agent experiment test what you think it tested?](https://chabot.dev/blog/did-your-agent-experiment-test-what-you-think-it-tested/): Wrong models, arms that never switched on, shifting workloads and features that ran without helping: checks that show an agent comparison contains the change.
- [Grading agents without trusting the simulator](https://chabot.dev/blog/grading-agents-without-trusting-the-simulator/): An evaluation lab where the oracle never calls simulator code, grades in ten gates, tests itself with mutations and can answer that it doesn't know.
- [Whose mistake did the coding-agent benchmark catch?](https://chabot.dev/blog/whose-mistake-did-the-coding-agent-benchmark-catch/): Reference and empty-patch controls, test-file collisions and environment faults: how to adapt a coding-agent benchmark and tell an agent's failure from the harness's.
- [Correcting the grader without rewriting the run](https://chabot.dev/blog/correcting-the-grader-without-rewriting-the-run/): A coding-agent evaluation whose first grader was wrong in both directions, and how original records, corrected verdicts and repairs stayed separate results.

## Giving an agent project a durable owner

What changes when a coding conversation becomes a project that keeps running while you are elsewhere, and what a coordinator and its workers need in order to stay useful when there are a hundred of them.

- [Giving an agent project a durable owner](https://chabot.dev/blog/giving-an-agent-project-a-durable-owner/): What has to change when a coding conversation becomes a project that keeps running while you are elsewhere: a coordinator added to existing threads, a record that outlives any one conversation, and an interface that won't infer one state from another.
- [Why a project worker needs to own the whole job](https://chabot.dev/blog/why-a-project-worker-needs-to-own-the-whole-job/): Why splitting implementation, review and follow-up into disconnected turns loses obligations, what belongs to the coordinator, the worker and its helpers, and the leases, anchored findings and content-bound checks that let ownership survive on a shared tree.
- [Keeping a coordinator responsive while its workers are busy](https://chabot.dev/blog/keeping-a-coordinator-responsive-while-its-workers-are-busy/): When a coordinator shares a process with its workers, load and every recovery action land on both. How the deciding agent was separated from the process that holds the tree, sandboxes and workers, what the relay between them costs.
- [Model concurrency is not machine capacity](https://chabot.dev/blog/model-concurrency-is-not-machine-capacity/): Why admitting sub-agent sessions and admitting work to a shared machine are separate problems, handled with queues, resource preflights, leases and useful refusals.

## Making an agent’s memory useful without slowing its next reply

Memory has to be isolated by tenant, keep the current fact in front, and stay out of the way of the next reply.

- [Making an agent’s memory useful without slowing its next reply](https://chabot.dev/blog/agent-memory-without-slowing-the-next-reply/): Capture, evidence, retrieval, projection and delivery can each fail alone. A small replay found a fact lost before search could see it, and 92 live calls carried no receipt that any memory had arrived.
- [Agent memory that remembers the current answer](https://chabot.dev/blog/agent-memory-that-remembers-the-current-answer/): Building a multi-tenant memory service where identity bounds access, later facts supersede earlier ones, and tests grade the final answer rather than retrieval.
- [Forgetting a memory must survive the retry that created it](https://chabot.dev/blog/forgetting-a-memory-must-survive-the-retry/): How a delayed create can bring a deleted memory back, and what stops it: durable operation receipts, a tombstone that keeps only the ID, supersession edges moved before a duplicate is forgotten, and recall whose staleness has a stated bound.

## What a tool-call approval actually approves

An approval should mean one tool call, with these exact inputs, in this thread and turn, under this version of the policy, once.

- [What a tool-call approval actually approves](https://chabot.dev/blog/what-a-tool-call-approval-actually-approves/): Binding a human yes to one tool call, with exact inputs, policy revision, thread and turn, spending it once across replicas, and asking where the last check sits.
- [Two ways a tool description goes stale](https://chabot.dev/blog/two-ways-a-tool-description-goes-stale/): Why a discovered tool definition is not permission to call it: re-checking catalog, policy and capability at call time, and deriving every format from one source.
- [Whose request is this? Delegated identity between services](https://chabot.dev/blog/whose-request-is-this-delegated-identity-between-services/): Keeping the calling service separate from the user behind it: absent, invalid and verified identity, binding claims to the resource, and what replay memory needs.

## Public code

- [mem0-rs](https://github.com/chrischabot/mem0-rs)
- [mem0-ts](https://github.com/chrischabot/mem0-ts)
- [agent-switchboard](https://github.com/chrischabot/agent-switchboard)
- [codex-swift](https://github.com/chrischabot/codex-swift)
- [open-cloud](https://github.com/chrischabot/open-cloud)
- [code-search](https://github.com/chrischabot/code-search)
- [severe-testing](https://github.com/chrischabot/severe-testing)
- [shindig-php](https://github.com/chrischabot/shindig-php)

[About](https://chabot.dev/about/)
[Projects](https://chabot.dev/projects/)
[Technical writing](https://chabot.dev/blog/)
[Essays](https://chabot.dev/writings/)

## Contact

Based in London.

chabotc@gmail.com
https://github.com/chrischabot
https://www.linkedin.com/in/chabotc/