Most agent projects fail the same way: unbounded tool access, no evaluation, and no record of what changed. We build the opposite — narrow tools, a test set before a prompt, and a log of every write.
Most of an agent system is ordinary software. Treating it that way is what makes the interesting part trustworthy.
Deterministic, not a model decision
The router that decides which agent handles a request is ordinary code, not an LLM. Routing is a classification problem with a known answer set — putting a model there adds latency, cost and a failure mode for no gain.
Shipped in D2CGPT: sixteen agents behind one chat surface, deterministic router.
The narrowest set that does the job
Each agent gets its own scoped tools over MCP. No blanket Admin API key. A merchandising agent cannot touch refunds; a support agent cannot edit the catalogue.
MCP servers we build and host, plus integration with servers you already run.
Retrieval over your systems, not the open web
Answers are grounded in catalogue, order, policy and inventory state. When the data layer returns nothing, the agent is required to say so rather than fill the gap.
Storefront and Admin APIs, order data, policy documents, CrUX field data.
Logged, reversible, approved
Anything that changes state is recorded with the prompt, the tool call and the result. Customer-facing actions wait on human approval. Every write has a rollback path.
Append-only action log, replayable, with per-action approval gates.
A test set before a prompt
We build the eval harness from your real transcripts first, then the agent. The suite runs in CI on every prompt or model change, so a regression is caught before a customer meets it.
Golden sets, failure-mode taxonomies, regression suites, quarterly re-benchmarking.
Agents need on-call too
Latency and cost budgets, drift monitoring, prompt and model version control, and an incident runbook for the night the agent says something wrong.
Versioned prompts, cost ceilings per conversation, alerting on quality drift.
Typed, observable, and mostly unremarkable. Every novel thing in an agent system is a thing that can fail at 2am, so we spend novelty carefully.
Model choice per task, not per project. Routing and extraction rarely need a frontier model.
The tool surface is the security boundary, so it is designed before any prompt is written.
An agent without an eval harness is a demo. We will not ship one.
Grounding comes from the systems of record, with retry and replay on every pipeline.
Boring, typed, and observable. The interesting part should be the agent, not the framework.
One conversation object across channels, so context survives the surface it arrived on.
Tell us what the agent would actually do and what it must never touch. We'll tell you which parts are production-ready today.
