Agent Control Workbench
What is an agent system?
An agent system combines a model with bounded tools, memory, policy, evaluation, and stop conditions so it can complete a task without silently expanding its authority.
Step 1
Model
Choose the task, topology, tools, memory boundary, write authority, runtime budgets, retry policy, guardrail response, and release threshold.
Step 2
Observe
Inspect which tools are permitted, every runtime step, tool latency and cost, the evaluation result, and the exact condition that completes, escalates, or stops the run.
Step 3
Challenge
Start with an approval-gated billing workflow, then inject a timeout, denial, context overflow, planner loop, or out-of-scope action. Change one control and trace the causal difference.
Design the authority. Then break the runtime.
Compose a vendor-neutral teaching fixture, run it under pressure, and inspect the exact policy gate, tool call, evaluation, and stop condition that shaped the outcome.
Loop 1
Compose capability and authority
Choose the job, topology, tools, memory, and write policy. The authority map updates before the runtime can execute.
Tool and permission envelope
Enable only capabilities the task can justify. Selection does not bypass the policy gate.
Exposure
62/100
Authority path
Request
Resolve a billing dispute
Planner
One decision loop
Policy gate
Approval gated
Tool boundary
4 of 4 tools enabled
Loop 2
Configure runtime and evaluation
Set budgets, retries, guardrails, and the release threshold. Then inject a scenario and inspect the resulting trace.
Ready to simulate
Healthy run with block guardrails
Run status
completed
Stop: task_complete
Latency
1,750 ms
3 tool calls
Tokens
5,480
$0.0249 fixture cost
Evaluation
95/100
Meets threshold 82
Auditable run trace
- 1
Classify request
Resolve a billing dispute. The planner receives a typed task, not an open-ended mandate.
120 ms460 tok - 2
Load bounded context
Session scoped: 3,500 of 6,000 tokens admitted.
80 ms3,500 tok - 3
Plan in one agent
One planner selects the smallest permitted tool sequence.
260 ms760 tok - 4
Call Account lookup
account.lookupRead one authenticated account
340 ms140 tok - 5
Approve exact refund arguments
approval.requestA reviewer approves $120 for the authenticated account. Later argument changes would require a new approval.
430 ms110 tok - 6
Execute bounded refund
refund.createThe tool validates tenant, amount, idempotency key, and declared $200 limit.
310 ms90 tok - 7
Return verified outcome
The response cites completed actions, pending work, and the trace identifier.
210 ms420 tok
Observed consequence
The task finishes inside the declared tool, memory, and authority boundaries.
Fixture pricing: $4 per million input-equivalent tokens plus $0.001 per tool call. Replace these assumptions with measured provider and infrastructure costs.
Implementation
Carry the control contract into code
These co-located examples are vendor-neutral teaching fixtures. They make authority checks, bounded retries, configuration, and evaluation explicit.
Model assumptions and limits
- Latency, token, evaluation, and cost values are deterministic teaching fixtures, not production benchmarks.
- The trace records decisions, tool arguments, approvals, and outcomes. It does not expose hidden model reasoning.
- Real systems must enforce authentication, tenant isolation, idempotency, rate limits, and tool-side validation independently.
- Evaluation scores illustrate release gates; they need domain-specific test sets and observed production outcomes.