TBW / AGENTIC AI / AGENTS
AI Agents
Build bounded AI agents for defined business tasks with explicit tools, permissions, evaluations and escalation paths.
AI Agents for Defined Work
We scope an agent around a specific task, a named owner and a measurable outcome. The agent may interpret variable inputs, but tools, permissions and consequential actions are bounded by policy. A fixed workflow remains preferable when rules already determine each step.
Agent Types and Their Risks
Research / summarization
Search and document retrieval support synthesis; verify citations and guard against unsupported conclusions.
Triage
Ticketing and classification tools route cases; incorrect routing needs detection and correction.
Drafting
Knowledge and templates support draft responses; review before any external send.
Data preparation
Read-only database/API access and transformation prepare datasets; classification and handling rules remain essential.
Operations assistant
Monitoring and approved operational APIs support investigation; broad action privileges should not be assumed.
Each type is a design pattern, not a ready-made autonomous product. Select the narrowest useful role and tool set.
Reusable Agent Card
For each proposed agent, document goal, owner, users, data classes, tools, allowed actions, prohibited actions, approval points, step budget, success measures, stop conditions and escalation path. Review the card with business and technical owners before any production access. A permission change requires a new review.
Agent Card Template
Complete each field for the proposed use case; this is a blank design checklist, not a deployed agent.
- Goal: The task and intended output.
- Owner: Accountable business and technical contacts.
- Users: Authorized audience and initiating identities.
- Data: Sources, classifications and tenant boundary.
- Tools: Named allowlisted tools and interfaces.
- Allowed actions: Permitted read, draft or approved-write operations.
- Prohibited actions: Explicitly denied operations and destinations.
- Approval points: Who approves which consequential actions.
- Step budget: Maximum steps, time and cost per run.
- Success measures: Representative cases and acceptance criteria.
- Stop conditions: Uncertainty, failed tools or exhausted limits.
- Escalation path: Who receives exceptions and how work resumes.
Boundary
Specify which records, tenants and destinations it may reach.
Decision
Describe exactly what the agent proposes versus what a person or policy must authorize.
Exit
State when uncertainty, a failed tool or exhausted budget stops work and alerts an owner.
Staged Build and Evaluation
Start in a sandbox with synthetic or test data and representative evaluation scenarios. Introduce read-only tools, then drafted actions, then approved writes where justified. Controlled production follows review of test results, access and escalation. Monitor after release and revisit scenarios as policies or models change.
Architecture separates the model’s reasoning from a policy-enforced tool layer and a traceable approval path; the model does not confer its own permissions.
Permission Staging: Least Agency
1 · No tools
Evaluate the task without access to systems.
2 · Read-only
Allow scoped retrieval; inspect source quality and access checks.
3 · Proposed action
Generate a draft or structured action without executing it.
4 · Approved action
Show the exact target and change to an authorized reviewer before execution.
5 · Limited autonomous action
Only for justified low-consequence actions with policy, limits and monitoring.
Least agency: advance permissions only when task evidence and controls justify them. Consequential actions need appropriate authorization.
Running Agents Responsibly
Observe step count, loops, tool calls, blocked actions, cost, latency, failures, human interventions and model/provider changes. Correlate a run with its agent card and policy version. Alert on repeated failures; stop rather than retry unsafe writes indefinitely. Keep sensitive payloads out of logs unless required and authorized.
What Not to Automate
Pause when the process is poorly understood, policy changes faster than controls, ownership is missing, data is unusable, success criteria are unclear or privileged actions are dangerous. Resolve the process or start with a read-only/drafting pilot instead of granting broad credentials.
Illustrative Agent Cards
Illustrative — design examples, not customer deployments.
Research brief
Goal: summarize an approved document set. Owner: research lead. Tools: scoped retrieval. Action: cited draft only. Stop: unsupported source. Escalate to analyst.
Intake triage
Goal: recommend ticket category. Owner: service desk. Tools: read ticket and approved taxonomy. Action: proposed routing. Stop: uncertain classification. Escalate to queue owner.
Operations investigation
Goal: explain alert context. Owner: operations lead. Tools: read-only telemetry. Action: incident draft. Stop: missing telemetry or repeated steps. Escalate to on-call engineer.
Implementation and Deliverables
Scope one task and its agent card; map data and tools; evaluate representative and failure cases; stage permissions; review control decisions; release with monitoring and rollback ownership.
Deliverables may include an agent card, architecture, tool catalog, access model, test scenarios, evaluation suite, control matrix and runbook.
Related: Agentic AI · Agent Design and Orchestration · Controlled Tool Access · MCP and API Integration
Frequently Asked Questions
What makes an agent different from a fixed workflow?
An agent interprets variable inputs or chooses among allowed steps; a fixed workflow executes predetermined rules. Use the latter when reasoning adds no value.
Can an agent begin without system access?
Yes. Start with no tools or scoped read-only access, then evaluate drafts before considering writes.
Who owns an agent after launch?
A named business owner defines the task and acceptable outcomes; operators monitor runs and escalate issues under a documented runbook.
How are agent actions approved?
Present the exact proposed change, target and context to an authorized reviewer or enforce an explicit policy gate before execution.
When should an agent project stop?
Stop when success cannot be measured, ownership or usable data is absent, or privileged actions cannot be bounded safely.
Scope a Bounded Agent
Bring a defined task, its data sources and the owner who can approve action boundaries. We can map the first agent card and evaluation plan.