Partner status
- Claude Partner Network member
- Claude Code partner badge — verify it on Credly
- Delivered from India and Germany across global time zones
- Founder-led engagements — senior advisors and the delivery engineers in one team
Getting an agent to answer questions is a weekend. Getting one to take actions against production systems — and stay trustworthy on the four-hundredth run — is an architecture problem. This is the pattern we use: Claude for the reasoning, MCP for every tool boundary, and a guardrail table written before any code.
1. The bottleneck this solves
In high-growth SaaS, Tier-1 and Tier-2 support queues become the constraint on scaling long before headcount does. Engineers spend most of their time on context-gathering rather than judgement: parsing logs, checking a tenant's state, querying a billing API, cross-referencing an internal wiki.
A chatbot answers documentation questions. An agentic workflow reads the ticket, looks up the tenant's actual state, takes a scoped corrective action through the same internal API a human would use, verifies the result, and replies — or escalates with its findings attached when it cannot.
Core objective
Verify, then reply
The agent does not assert that its fix worked. It re-queries system state after acting and only then responds — so a confident wrong answer becomes a caught failure rather than a customer-facing one.
2. Architecture: Claude for reasoning, MCP for every boundary
The reasoning engine is Claude — Claude Opus 5 for planning and anything involving judgement, Claude Sonnet 5 for the high-volume classification and extraction steps where the cost difference matters and the task is well specified.
Every capability the agent has reaches it through a Model Context Protocol (MCP) server. This is the decision that does the most work in the whole design. Instead of tools defined inline in application code, each system the agent touches gets its own MCP server with its own scope: one for the ticketing platform, one exposing read-only database views, one wrapping the internal administration API.
That boundary buys three things. Permissions are enforced per server rather than per prompt, so a misbehaving model cannot reach past what its servers expose. The same servers are reusable across agents and by engineers working in Claude Code, so tool definitions stop being written twice. And the guardrail table — which actions run automatically, which need a human, which do not exist — maps directly onto server scopes instead of living in a prompt where it can be argued with.
graph TD
T[New support ticket] --> Q[Durable queue with DLQ]
Q --> Orch[Orchestrator: tool-use loop]
Orch --- Claude[Claude Opus 5: plan and decide]
subgraph MCP["MCP servers - one scope each"]
direction LR
M1[Ticketing]
M2[Database: read-only views]
M3[Admin API: scoped write]
end
Orch --> MCP
MCP --> V[Re-query state to verify]
V --> D{Verified?}
D -->|Yes| R[Reply and close ticket]
D -->|No| E[Escalate with findings attached]
Writes never go direct to the database. They pass through the same authenticated internal administration API a human operator would use, so the agent cannot bypass the validation and business rules that already exist in the backend. The orchestrator itself runs under a restricted role, and each MCP server holds its own credentials rather than sharing one over-scoped key.
3. The loop, and what a good failure looks like
Claude plans, calls a tool, reads the result, and decides again. The interesting part is not the happy path — it is what happens at the point the agent runs out of permission or certainty. Below is a real-shaped trace where the agent hits an authorization boundary and escalates rather than improvising.
System: Ticket #8842 — "My tenant
dashboard is not loading after the recent feature toggle."
Thought 1: I need the tenant ID for this
customer before I can check anything else.
Action 1: ticketing-mcp → `lookup_tenant`
{"email": "user@example.com"}
Observation 1: Tenant_ID: 942A.
Thought 2: Check the feature flag state for 942A
against the admin API.
Action 2: admin-mcp → `check_flags`
{"tenantId": "942A"}
Observation 2: 401 Unauthorized — this MCP
server's scope does not include the flags endpoint.
Thought 3: This is outside my boundary. I cannot
resolve it, and I should not try another route to the same data. Escalate with what I have.
Action 3: ticketing-mcp → `escalate`
{"queue": "tier-2", "notes": "Tenant 942A. Flag state unread:
agent scope excludes the flags endpoint."}
Two properties matter here. The agent stopped at the boundary instead of guessing, and the escalation carried its findings forward so the human did not restart from zero. An agent that escalates emptily has moved the work rather than removed it.
4. Phased rollout
Nobody should switch this on in one cutover. The line between propose and act moves outward on evidence, across three phases.
Phase 1: Shadow mode (weeks 1–4)
The agent sees live traffic and holds zero write permissions. It drafts private internal notes proposing what it would do. Engineers review the proposed tool calls, and that feedback tunes the tool schemas and the boundary — not just the prompt.
Phase 2: Read-only triage (weeks 5–8)
Read scopes are enabled on the database and log MCP servers. The agent appends context to new tickets and routes them to the right team, which removes the dispatcher step without giving it the ability to change anything.
Phase 3: Scoped autonomy (weeks 9–12)
Write scopes are enabled for named, deterministic, reversible actions. Each one is a row in the guardrail table with an owner against it. Everything else still escalates.
5. What it returns
- Resolution time: hours to seconds for the L1 tasks that clear the boundary, with everything else routed faster and better-annotated.
- Engineering focus: senior engineers reclaim the sprint capacity previously lost to interrupt-driven escalation.
- Documented systems: exposing tools through MCP forces the organization to define its internal APIs properly. The artefact outlives the agent.
- A measurable boundary: escalation rate becomes a monitored number, which is what lets you widen autonomy on evidence rather than optimism.