A managed AI agent should own one bounded business function—not “the business.”
That function might be preparing a lead for human follow-up, assembling a draft briefing from approved sources, or checking whether a delivery handoff is complete. The agent may make limited decisions inside that function, but its operating contract must define what starts the work, what information it may use, what it may decide, what it must produce, and when it must stop.
“Managed” describes the ownership around the agent. Someone still has to approve the business rules, maintain the company context, monitor the system, handle incidents, and decide when the workflow changes.
If you are still choosing the workflow, use the AI project readiness scorecard before evaluating an agent.
1. Define the function before choosing the agent
A useful scope answers six questions:
- Inputs: What event starts the work, and which information is required?
- Decisions: Which choices may the agent make, and under what rules?
- Outputs: What record, draft, recommendation, or handoff should it produce?
- Completion: What observable condition means the work is done correctly?
- Non-goals: What related work is explicitly outside the agent’s authority?
- Escalation: Which conditions send the work to a named person?
“Handle new leads” is not bounded. A clearer scope would be:
Review each new website inquiry against the approved service-area and qualification rules, create a complete internal summary, and route uncertain or high-value exceptions to the sales owner. Do not quote a price, promise availability, or send a customer message without the required approval.
That statement gives the team something to test. It also prevents a narrow workflow from quietly expanding into unrestricted authority.
OpenAI’s practical guide to building agents distinguishes agent-suitable work—where nuanced decisions, difficult rules, or unstructured information matter—from work a deterministic solution can handle. Anthropic’s guide to building effective agents similarly recommends starting with the simplest design that meets the need. The decision is not “AI or no AI.” It is the least complex operating model that can perform the function reliably.
2. Give the agent current, authoritative company knowledge
An agent cannot apply company judgment from a generic prompt. It needs approved context for the function it owns, including:
- policies and service boundaries;
- pricing logic and the conditions around it;
- relevant customer or account context;
- known process exceptions;
- the history needed to understand the current situation;
- examples of acceptable and unacceptable outputs.
More information is not always better. Conflicting documents, stale instructions, and unlabeled examples make the system less dependable. Every source should have an authority level, an owner, and a freshness rule.
For example, the current service policy may outrank an old proposal. A signed customer agreement may outrank a general delivery checklist. An example can show tone or format without becoming permission to reuse its facts.
Before launch, document:
- where each source comes from;
- which source wins when two sources conflict;
- who approves corrections;
- how quickly a material change must reach the agent;
- what the agent should do when required context is missing or uncertain.
The client owns the truth of its policies, customer commitments, and exceptions. A managed provider can organize, connect, test, and maintain those sources, but should not invent business policy.
3. Limit access to what the function requires
Access should follow least privilege: the agent receives only the accounts, data, and actions needed for its bounded function.
That may include credentials, account permissions, integration scopes, and a dedicated identity when separation improves control or accountability. A dedicated identity is not automatically necessary, and it is not a substitute for narrow permissions, credential rotation, or access review.
Start with read-only or draft-producing access where possible. Add write actions only after the team has tested the normal path, exceptions, duplicate handling, and failure recovery. Prefer actions that can be reversed. Log who or what initiated each consequential change, the information used, the result, and any approval attached to it.
Do not grant unrestricted payment, account-administration, deletion, or customer-communication authority simply because an integration supports it. High-consequence access requires stronger approval, spending or action limits, monitoring, and a manual fallback.
If the work is a stable trigger followed by a predictable action, the small-business automation guide may point to a simpler approach. A managed agent is more appropriate when the function requires contextual judgment or exception handling that cannot be expressed as fixed rules alone.
4. Put human approvals and escalation paths in writing
A person should approve actions that create a high-cost, hard-to-reverse, or externally binding result. Common examples include:
- spending money or changing a financial record;
- making a customer promise about price, scope, timing, or eligibility;
- approving an exception to policy;
- deleting records or changing access;
- publishing or sending sensitive external communication;
- continuing when required information is missing or contradictory.
An approval step needs more than “ask a human.” Name the role, show the information the reviewer receives, define the response time the workflow can tolerate, and specify what happens if nobody responds.
Escalation rules should also include stop conditions. The agent should pause when confidence is inadequate, a source is stale, permissions change, a tool is unavailable, volumes depart from expected ranges, repeated errors appear, or the requested action falls outside the defined function.
The business owner retains authority over policy and customer commitments. The provider owns the technical route to the reviewer and the reliability of the escalation mechanism. The agent owns only the act of recognizing and routing conditions included in its approved instructions.
5. Treat launch as the start of ownership
An agent is not managed because someone configured it once. It is managed when the operating team can see whether it is working, respond when it is not, and update it without losing control.
Start with measurable acceptance criteria. Depending on the function, they may include:
- every test input creates exactly one expected output;
- required fields are complete and traceable to approved sources;
- prohibited claims and actions never pass the approval boundary;
- exceptions reach the named owner with enough context to decide;
- failures are visible within an agreed interval;
- the manual fallback can keep the function operating;
- a rollback returns the workflow to the last accepted version.
Observability should show outcomes, not only whether software is running. Track successful completions, exceptions, approval waits, tool failures, rejected outputs, and unresolved work. Incident response should name who investigates, who can pause the agent, how affected records are reconciled, how the business operates during the interruption, and who authorizes restart.
Changes need the same discipline. A revised policy, new service, integration update, or customer exception may require source updates, new tests, permission review, or different escalation rules. Use a review cadence based on how quickly the function changes and how costly a failure would be—not an arbitrary claim that the system can run unattended.
NIST’s AI Risk Management Framework Core organizes ongoing work around Govern, Map, Measure, and Manage. For a service operator, that becomes a practical owner map:
| Role/system | Operational responsibility |
|---|---|
| Agent | Execute the approved function, log its work, and escalate defined exceptions |
| Managed provider | Configuration, integrations, tests, technical monitoring and maintenance, technical incident response, rollback execution, and approved updates |
| Client owner | Business policy, source authority, customer commitments, exceptions, approvals, access authorization, business continuity, affected-record decisions, and acceptance of rollback and restart |
Names should sit behind those roles. “The provider” and “the client” are not useful incident contacts without a responsible person and backup.
Managed agent vs. automation vs. virtual assistant
| Decision factor | Managed AI agent | Deterministic automation | Virtual assistant |
|---|---|---|---|
| Contextual judgment | Applies approved context to bounded decisions and escalates uncertainty | Follows explicit rules; little or no judgment | Uses human judgment across varied situations |
| Repeatability | Best when the objective repeats but inputs or paths vary | Best when the trigger, rules, and result are stable | Can handle changing work, but consistency depends on training and process |
| Exception rate | Handles defined variation; routes novel or high-risk cases | Works best when exceptions are uncommon and easy to detect | Often suitable when exceptions are frequent or poorly documented |
| Operational ownership | Provider maintains the system; client retains policy and approval ownership | Internal or external owner maintains connections, rules, and failures | Manager owns priorities, training, access, quality, and coverage |
| Best fit | Repeated function requiring context, multiple tools, and controlled decisions | Predictable handoff or calculation with fixed rules | Broad, changing work that benefits from direct human interpretation |
These options can work together. An agent may use deterministic automations for stable handoffs and escalate unusual work to a virtual assistant or internal owner. The goal is not maximum autonomy. It is the clearest division of labor.
Buyer readiness checklist
Before asking a provider to build or manage an agent, confirm:
- One business function is named in plain language.
- Inputs, outputs, completion, non-goals, and escalation conditions are written.
- The workflow occurs often enough to justify ownership.
- Authoritative sources and their owners are known.
- Required data is permitted for the proposed accounts and workflow.
- Permissions can be limited to the function.
- High-risk actions have named human approvers.
- Acceptance criteria cover normal work, exceptions, and prohibited actions.
- A manual fallback and stop authority exist.
- Someone inside the company owns policy and customer commitments.
- The provider’s monitoring, incident, rollback, and update duties are explicit.
If several boxes remain open, discovery should clarify the process before implementation. A half-defined function will not become well managed by adding a more capable model.
Questions to ask a managed-agent provider
- What exact function will the agent own, and what remains outside scope?
- Which decisions can it make without approval?
- How will you identify authoritative company sources and keep them current?
- Which accounts, credentials, and permissions are required?
- Can we begin read-only or in draft mode?
- Which actions are reversible, logged, limited, and subject to approval?
- What tests must pass before launch, and who accepts the result?
- How will we see completions, exceptions, failures, and waiting approvals?
- Who responds to an incident, and what are the pause, fallback, reconciliation, and restart steps?
- How are policy changes, integration changes, and new exceptions reviewed?
- What does the provider maintain, and what must our team continue to own?
- What evidence supports any outcome claim you make?
What this article and episode can prove
The source Build With AI episode shows examples of agent provisioning, operating environments, reusable templates, and observation interfaces. It also discusses provider responsibility for onboarding, deployment, maintenance, and support. Those demonstrations are useful source context; they do not verify customer identity, commercial outcomes, or complete end-to-end autonomy.
Return My Time does not currently have a measured managed-agent client case study. This framework describes an operating model and buying standard, not a promise of revenue, savings, or another business outcome. You can browse the full Build With AI podcast archive for more implementation context.
If one business function is important enough to manage but too complex for a simple automation, book a discovery call. The call is used to qualify fit and scope the required assessment before any managed-agent work. It is a place to define the operating contract—not a guarantee that an agent is the right answer.
