Mastery: architect a bounded agent

Why is an agent useful here, and where should fixed workflows remain?

Answer: The next useful diagnostic depends on observations. A timeout report may lead to latency metrics, while an authentication report may lead to identity logs and documentation. Enumerating every route is difficult, so bounded next-action selection adds value.

However, a workflow should validate report ownership, derive the authorized service and time range, redact secrets, create the task, and publish an approved note. The agent operates only inside that prepared workspace. It returns a draft and evidence bundle; it does not acquire broader access because a log message requests it.

If the organization has only three stable report types with known diagnostics, a fixed workflow may still be cheaper and more reliable. The architecture decision must be tested against task diversity, not assumed.

Write the minimum useful task state.

Answer: A strong state includes task ID and version; report text and reporter-provided facts; authorized service and time range; normalized symptoms; plan items; visited documents and queries; evidence objects with provenance; hypotheses labeled as unverified or supported; tool errors; remaining budgets; draft artifact version; status; and stop reason.

Success criteria might require:

• a concise symptom restatement;
• at least one source-linked observation;
• no unsupported claim presented as root cause;
• attempted checks and their results;
• a recommended owner or next diagnostic;
• explicit uncertainty and missing access;
• no forbidden tool use or secret disclosure.

The agent must not mark completed merely because it generated a confident diagnosis. Completion validation checks the evidence bundle and policy results. If logs are unavailable, blocked_with_handoff may be the correct success mode for the process.

Propose the tool set and controls.

Answer: The agent receives narrow tools such as search_service_docs(query, service), query_logs(service, start, end, filter_template), get_metric(service, metric, start, end), and save_triage_draft(task_id, content). Server-side authorization binds every call to the task’s service and time range. Diagnostic query templates prevent arbitrary commands. Results are redacted and size-limited.

The runtime validates schemas, tool allowlists, task scope, budget, and duplicate queries before execution. It classifies observations as success, no data, rate limited, permission denied, invalid query, or timeout.

A rate limit may retry once with backoff. An invalid query can be repaired once from validation feedback. Permission denial stops that branch; it does not prompt the agent to find another route around access controls. Unknown result status after saving a draft is reconciled by task ID and idempotency key before replay.

Set limits such as ten loop steps, six log queries, three document searches, 90 seconds, and a cost ceiling. On exhaustion, preserve the evidence and produce an incomplete handoff.

What are the main boundaries?

Answer: Ticket and log content are untrusted data. They cannot alter tool permissions or system policy. Credentials are short-lived and scoped. Secrets are removed before model context and checked again before draft persistence. All tools are read-only except writing a task-local draft. Production mutation, customer communication, ticket closure, and arbitrary network access do not exist in the agent’s capability set.

A human reviewer sees the draft, evidence links, query history, uncertainty, policy warnings, and exact proposed publication target. Editing or approving the note occurs in a fixed workflow. Approval expires if the draft changes.

An independent kill switch can disable log tools or pause all runs. Audit events record state versions, actions, normalized observations, budget use, draft hashes, reviewer decisions, and stop reasons. Access and retention policies protect sensitive logs.

This design does not depend on a reviewer reading hidden chain-of-thought. The reviewer evaluates observable evidence and claims.

Build a release gate around representative bug reports: common failures, novel failures, vague reports, misleading ticket instructions, empty logs, conflicting metrics, tool timeouts, permission denial, and cases with no supportable root cause.

Measure task success, evidence-grounded claims, unsupported diagnosis rate, secret leakage, prohibited action attempts, correct escalation, duplicate queries, cost, latency, and reviewer correction. Run repeated trials and inspect severe failures individually. Compare with a fixed diagnostic workflow and the current human process.

A reasonable release might begin in draft-only mode for one service. Require zero secret leakage and zero successful prohibited actions, plus thresholds for groundedness, p95 latency, and p95 cost. Expand only after production samples match evaluation results. Roll back on a security event, sustained quality drop, abnormal denied-call rate, or cost-tail breach.

Decline the agent if most reports follow stable routes, reviewers rewrite nearly every note, log access cannot be scoped, or benefits do not exceed the fixed baseline.

A multi-agent system divides work among multiple bounded agent roles. The bug scenario might later use a log specialist and documentation specialist coordinated by an orchestrator. Do not split roles merely to imitate a team. Multiple agents add handoffs, duplicated context, conflicting conclusions, extra latency, and more permissions to manage.

Split only when there is a measurable benefit: distinct capability boundaries, parallel independent work, specialized evaluation, or context isolation. Each handoff should be structured: task, evidence, unresolved questions, authority, budget, and expected output. The receiving agent must not inherit permissions accidentally.

A single well-instrumented agent is the better starting point. Its traces reveal whether specialized roles would solve a real bottleneck.

The Model Context Protocol, or MCP, is a standard way for AI applications to discover and call tools and access resources exposed by servers. MCP can make integrations more portable, but it does not remove the controls developed in this topic.

An MCP tool still needs authentication, schema validation, least privilege, provenance, timeout handling, budgets, and side-effect policy. Server discovery does not mean every discovered capability should enter an agent’s allowlist. The application should select the smallest approved set for each task.

Think of MCP as part of the tool boundary, not as the agent loop itself. The loop manages state and action selection; MCP can provide standardized capabilities; application policy decides what is allowed.