Selected work · agentic support platform
An AI support platform where a fleet of narrow agents classifies, retrieves, resolves, and guards every case. Teams define their own modules, schemas, policies, and workflows. MCP servers and APIs connect the fleet to the systems those answers actually live in. Every write action stops at a human approval gate, and every case carries a trace that explains it.
Senior Full-Stack Engineer / Backend Architect
2024 to 2025
agentra · fleet, mcp layer, approvals, traces
Agentra is a customer support platform built as a coordinated fleet of agents. A case arrives from a chat widget, an inbox, a help desk, or a messaging app, and the fleet classifies it, finds the answer, drafts the reply, and decides whether a person needs to see it first.
The part that makes it a platform rather than a bot is the layer above it. A team defines its own modules, the schemas its agents may reason about, the policies that bound them, and the workflows a case follows. Agentra adapts to how that product actually operates instead of asking the team to describe their business in a prompt.
Support tooling is fragmented by default. The answer to one refund question lives in an orders database, the rule that governs it lives in a policy document, the evidence lives in an attachment, and the action lives in a payments system nobody wants a model touching unsupervised. Every case is a manual join across four systems, done by a person under an SLA.
Automating the join is the easy half. The hard half is that the last system on that list is the one that moves money, and the honest answer to who may call it is almost always not the model on its own. So the constraint shaping the whole product was never accuracy. It was permission.
Nothing is granted by default
Discovery finds what a connected system can do. It does not decide what the fleet may do. Every tool on the right starts switched off, and a person turns each one on at read, needs approval, or nothing at all.
What one refund request has to touch
The system reads as four layers. At the top, a tenant defines its modules, schemas, workflows, and policies, and each of those definitions governs one agent. Below it, the fleet runs in a fixed order: the classifier routes, the retriever gathers, the resolver drafts, the guard checks. Below that is the connection layer, where every side effect lives and every tool carries the tier it was granted. At the floor is the person who signs off.
reads can fan out freely. the one write path stops at the approval gate.
The connection layer is the part a team actually sets up. Agentra is pointed at an MCP endpoint, inspects it, and lists what it found: the tools, their schemas, and their limits. Nothing is enabled by that discovery. The ops team grants each tool a tier, and the product then restates in plain language what the fleet can newly do, agent by agent, before any case touches it.
One tool in the diagram has no line reaching it. The warehouse api is connected and switched off. That is the point of having tiers at all: an ungranted tool is unreachable regardless of what a model decides to call.
One ticket, followed the whole way through. A customer reports a cracked lantern and asks for a refund. What follows are four production captures of that same case: where it lands, how the fleet reasoned about it, where it stopped, and what the person on the other end was handed.
One case, four beats
Order SG-18274 arrives as a chat message with a photo attached. What comes back is a drafted reply, a refund held at an approval gate, and a trace that explains both. Nothing is sent until a person says so.
queue 8 of 31 · cs-4821 · sla 38m left
Eight cases are waiting on a person, out of thirty one in flight. Open one and the whole thread is there: what the customer wrote, what the fleet drafted, and every step it took to get there.
classifier 0.8s · retriever 6.2s · resolver 28.4s · guard 41.0s
Four narrow agents, in order, each with its own job and its own tool calls. The trace is the record: what was classified, what was retrieved, what was drafted, and what the guard checked before the reply was allowed to send.
payments.create_refund($42.50) → queued · awaiting approval
The resolver can draft a refund. It cannot issue one. The write action stops at an approval gate, and the case surfaces three choices: send the draft, edit it, or take the case over entirely.
policy §4.2 · outside return window · manager approval
When policy says a person has to decide, the fleet says so in plain language and hands over a summary: the order, the evidence, the rule that blocks it, and the action it suggests. Nobody has to repeat themselves.
Classifying an intent, finding the right order and policy, drafting a reply, and checking that reply against the rules are four different jobs with four different risk profiles. One agent holding all of them is a single prompt nobody can evaluate. Splitting them into a classifier, a retriever, a resolver, and a guard keeps each job small enough to test on its own, and makes the sequence legible in the trace.
Impact·A wrong classification gets caught downstream instead of becoming a wrong customer answer, and each agent can be changed without reasoning about the other three.
Every tenant runs on a different set of systems. Hand writing an integration per customer does not scale, and stuffing capabilities into prompts makes them untestable. Pointing Agentra at an MCP endpoint and letting it inspect the tools, schemas, and limits on the other side turns integration into a connection step. REST APIs get the same treatment through a thin adapter.
Impact·A new tenant system becomes a connection, not a release. The same typed tool surface is what every agent sees, so tools can be tested without a model in the loop.
An agent that can issue refunds is a security decision before it is a product decision. Discovery finds what a system can do; it does not decide what the fleet may do. Each discovered tool sits at read, needs approval, or off, and the ops team sets that per tenant. The product then states in plain language what the fleet can newly do, before a single case touches it.
Impact·Blast radius is a setting, not a code path. A tool nobody enabled is unreachable no matter what the model decides to call.
Deflection is easy to optimize into something worse than a queue. Rather than tuning a confidence threshold and hoping, write actions stop at an approval gate by default. The resolver produces a complete draft and a queued action, and the case surfaces three real choices: approve, edit, or take it over. Reads never block.
Impact·Nothing customer facing or money moving ships without a person, and the human queue is short because the work arriving in it is already done.
The usual failure of a support handoff is asking the customer to repeat themselves. When policy will not let the fleet decide, it says so to the customer and hands the teammate a summary: the order, the evidence it verified, the rule that blocks the action, and the action it suggests. The rule that triggered the escalation is named, so the human knows what they are being asked to override.
Impact·The person picking up a case starts from a decision, not from reading. The customer is told a human is coming and why.
An agent trace is not a request trace. The interesting spans are turns, tool calls, and handoffs, and the attribute that hurts is dollars, not milliseconds. Emitting every event once onto a shared bus, then subscribing sinks to it, made adding a new destination one call instead of a rewrite. Prompt caching means the invoice cannot be derived from a token count, so the precomputed total is the number that lands in the UI.
Impact·Per case cost and the full reasoning trace are visible while a case is still open, and a new dashboard is a subscriber rather than a project.
Picking an agent runtime on a launch post is guessing. Before committing, the same support crew was built three times over: on Flue, on Cloudflare's Think, and on AWS Bedrock AgentCore with Strands. That comparison is where the real differences showed up, in where subagents run, how retries handle side effects, how memory is scoped, and how much wiring observability costs.
Impact·The runtime decision came with the tradeoffs already measured, and the two writeups below are the notes from it.
Goes deeper