Risk, autonomy, and the agent lifecycle
A practical framework for thinking about how much autonomy to give your agents, when to put a human in the loop, and how to move an agent safely from idea to production. Pair it with our security and governance features on the platform.
Guide · Agent design
Match the controls to the risk
Not all agents carry the same risk. A read-only research assistant is fundamentally different from a customer-facing agent that can send emails and modify databases. Start by figuring out where on the spectrum your agent sits, then pick the controls that match.
A simple way to think about it
Imagine you are hiring someone new. Do they need access to the company bank account? Probably not. Most jobs do not require it, and removing that access entirely eliminates a whole category of risk.
What if they need both customer data AND email? Now you have a leak vector. They could accidentally, or be manipulated into, sharing sensitive information externally. So you think about safeguards: separate the tasks, require approval for external emails, restrict email to specific domains, monitor closely at first.
The same logic applies to agents. The platform gives you the tools (guardrails, approval requirements, monitoring), but you decide which ones are appropriate for each agent.
Risk vs reward
An agent that scores "lower risk" across all factors needs minimal guardrails. An agent that scores "higher risk" on several factors may be more valuable, but needs serious attention to security configuration.
| Factor | Lower risk | Higher risk |
|---|---|---|
| Scope | Specific, narrow task | Broad responsibilities |
| Tools | Read-only access | Write, send, call, delete |
| Communication | Internal team only | Customer-facing, public |
| Data access | Public information | Confidential, PII, financial |
| Reversibility | Easy to undo | Permanent or hard to reverse |
Scope
Lower risk
Specific, narrow task
Higher risk
Broad responsibilities
Tools
Lower risk
Read-only access
Higher risk
Write, send, call, delete
Communication
Lower risk
Internal team only
Higher risk
Customer-facing, public
Data access
Lower risk
Public information
Higher risk
Confidential, PII, financial
Reversibility
Lower risk
Easy to undo
Higher risk
Permanent or hard to reverse
Who decides, agent or human?
Autonomy is a spectrum, not a switch. Start with more human oversight and give the agent more rope as it proves itself.
Agent decides
When to use
Low-stakes, reversible actions where speed matters
Example
Setting ticket priority
Agent decides, informs human
When to use
Medium-stakes actions where visibility matters
Example
Sending internal status updates
Agent suggests, waits for approval
When to use
Higher-stakes decisions where human judgement adds value
Example
Issuing a customer refund
Agent asks human to decide
When to use
Critical decisions, edge cases, ambiguous situations
Example
Escalating a complaint to leadership
Principle of earned trust: start narrow, and expand as the agent proves itself.
A path from idea to production
A reference flow for moving an agent from concept to live use. Most teams adapt this to their own context, but the stages and the checks at each step are a useful starting point.
Idea
Team
Start with the Agent Design Canvas: purpose, value, triggers, inputs, action plan, interfaces, knowledge, capabilities, output, and definition of done.
Prototype
Sandbox workspace
Safe experimentation on synthetic or redacted data. Limited capabilities, no unrestricted live data. Tagged "Playground".
Review candidate
Team + Platform tooling
Apply shared standards, naming conventions, and ownership metadata. Pass an internal compliance check before promoting.
Risk-tier approval
Self-cert, team admin, or governance
Routed to the right approver based on tier. Low risk self-certifies, medium risk goes to a team admin, high risk to platform governance.
Reviewed pilot
Business workspace
Tuning on real business context with explicitly scoped permissions, budget guardrails, monitoring, and a rollback path.
Production
Owning team
Team-owned, team-funded, team-monitored. Production agents keep their audit trail, approval queue, and usage limits in place.
Tiered approval, a sample framework
Bottlenecks happen when every agent needs the same review. A tiered model lets governance focus on the cases that actually need it. Use it as a starting point and adapt to your own organisation.
| Tier | Approver | Criteria |
|---|---|---|
| Tier 1 · Low risk | Self-certified by team lead | Internal use only, read-only data access, no sensitive or personal data, no financial actions. Passes the team's standard checklist. |
| Tier 2 · Medium risk | Team admin (governance champion) | Internal write access, non-public internal data, automated internal actions like ticket creation. Pilot uses explicitly scoped permissions and spend limits. |
| Tier 3 · High risk | Platform & governance review | Customer-facing, sensitive or regulated data, financial or contractual actions, third-party integrations, organisation-wide impact. Formal sign-off and rollback controls required. |
Approver
Self-certified by team lead
Criteria
Internal use only, read-only data access, no sensitive or personal data, no financial actions. Passes the team's standard checklist.
Approver
Team admin (governance champion)
Criteria
Internal write access, non-public internal data, automated internal actions like ticket creation. Pilot uses explicitly scoped permissions and spend limits.
Approver
Platform & governance review
Criteria
Customer-facing, sensitive or regulated data, financial or contractual actions, third-party integrations, organisation-wide impact. Formal sign-off and rollback controls required.
This is a design pattern, not a built-in workflow. You implement it using the platform building blocks (team admins, user approval, capability access tiers, credit limits).
Ready to put this into practice?
Use the Agent Design Canvas to design your next agent. See the security and governance pages for the controls the platform provides.