Assess implementation through deliverables, acceptance evidence and dependencies. Agree the job and authority, verify connections and outcomes, and hand over an operating routine with clear responsibility.
What you'll learn
- What each implementation phase should deliver and demonstrate
- How to estimate work, waiting and ongoing operation separately
- How to test real requirements without uncontrolled live consequences
- What the business, partner and operator should agree before launch
Ask what each implementation phase delivers, how it will be accepted and what it depends on. Scope, connections, controls, testing and operation need clear decisions and evidence; the actual remaining work determines the estimate.
An AI agent implementation turns an agreed job into a workflow with usable inputs, permitted actions, working connections, tests and operating responsibility. Ask what each part will deliver, how it will be accepted and what it depends on. Those answers help you assess a proposal and understand changes to its scope or schedule.
The business and implementation partner need to work together. The business supplies process knowledge and authorises the intended job; the partner explains technical options, implements the agreed controls and demonstrates the result. Record unresolved questions instead of letting either side assume the other has answered them.
What should you expect beyond setting up the agent?
Expect decisions about the work, access and consequences as well as configuration and development. A tool connection or a successful demonstration may already cover part of the job. Inspect what is ready, identify the remaining deliverables and agree who can accept them before enabling the affected live actions.
For example, a demonstration might prepare a correct follow-up draft but leave the intended recipient rule or the manual route for a missing invoice unresolved. The next work is to decide and test those conditions, not simply run the same demonstration again.
Bring ongoing ownership into the proposal too. The operator needs a way to report a problem, the maintainer needs access to investigate it and a business owner needs authority to decide a scope change. The post-launch handover should make those arrangements usable.
How do you estimate the implementation work?
Estimate from deliverables, dependencies and evidence still needed, rather than copying a standard number of weeks for each phase. Ask which work can overlap, what access or decisions the business must supply and what findings would change the estimate. Keep implementation effort, waiting for decisions and ongoing operating work distinct.
The following phase map is a practical organising structure. A project can revisit a phase when tests expose a missing rule or a connection behaves differently from expected.
| Phase | Deliverable to estimate | Where the work goes | Acceptance question |
|---|---|---|---|
| Scoping | Agreed initial job and example outcomes | Inputs, exclusions, business rules, success criteria | Do process owner and builder agree on the intended result and exceptions? |
| Connections | Permitted operations in each required system | Access, record identity, field mapping, retries and failure handling | Does the operation reach the correct destination within its rights? |
| Build and controls | Working logic with enforced action boundaries | Approval, refusal, expiry and exception routing | Do allowed actions work and prohibited actions remain blocked? |
| Representative testing | Results against agreed ordinary and consequential cases | Preparing examples, checking outcomes, repairs and repeated tests | Does the evidence meet the agreed criteria for the launch scope? |
| Ongoing operation | Named responsibilities, response and change arrangements | Reviewing work, repairs, provider notices and business changes | Can the operator find help, pause affected work and use the manual alternative? |
A short project can reuse existing decisions and connections; a longer one can have legitimate access, data or process dependencies. Ask for the reason behind the duration. The schedule alone does not show that work was skipped or that scoping was poor.
What does scoping the workflow involve?
Scoping defines eligible requests, expected results, permitted sources and actions, and cases that need a person. The process owner and partner should work through examples together. Technical exploration can help reveal constraints, but the business must authorise decisions with business consequences before those actions run live.
For a follow-up task, decide which contacts are eligible, the event that starts it, what source information it may use, who may receive the result and when a human decision is needed. Include a reply, cancellation, missing record and conflicting source value, rather than documenting only the ordinary path.
Keep the first job as simple as the need allows. Anthropic’s agent-building guidance recommends starting with a suitable simple solution and adding complexity when needed.[1] If an ordinary rule or a prepared draft meets the requirement, the partner should explain the benefit and extra operating burden of a more independent design.
How do you connect systems and define controls?
Define each required read, write, send and handoff, then grant only the access needed for the approved job. Verify the source and destination records and agree the human decisions before implementing consequential actions. The business decides the authority; the partner must show how the configuration enforces it.
Connections need correct identity and field mapping as well as a successful login. Test missing or duplicate records, rejected writes and retries. Record who supplies access and who receives provider change notices. A shared account can grant more access than the task needs, so inspect its actual permissions.
For the control layer, specify which exact proposal a reviewer sees, what remains held and what happens on rejection, changes or no response. Test an unavailable review route. A rule in a document needs implemented restrictions; a product setting needs the right policy and a test of its actual behaviour.
Ask what must be decided, built and demonstrated, and who can accept each result.
How do you test under realistic conditions?
Use representative permitted inputs and expected outcomes while keeping test activity apart from live consequences where possible. Include ordinary work, missing information, conflicts, repeated requests and actions that must be refused or referred. Synthetic or appropriately prepared records can be useful alongside suitable real examples; realism does not require uncontrolled live sends or writes.
Agree the judging rules with the person who knows the workflow. Check factual correctness, destination, required approvals and the work left for people. Distinguish a serious record or recipient error from an optional style edit when accepting the result.
Inspect the actual outcome, not just the agent’s success message. A proposed update, an accepted connection request and the correct saved record are different things to check.
Anthropic’s evaluation guidance separates an agent’s account from the final state in its environment and recommends testing desired and undesired behaviour.[2] For your workflow, open the destination record or inspect the delivered result, and check a similar-looking request that should not be executed.
After a repair, repeat the affected case and previously working tasks that could be changed by the fix. Keep unresolved issues with an owner and a decision about the permitted launch scope. Passing one set of tests does not remove the need to monitor actual operation and respond to new cases.
What evidence supports a launch decision?
Review the agreed outcomes, permission boundaries, test results, unresolved issues and operating arrangements together. The process owner and partner should be able to explain what is accepted, what is excluded and which findings prevent a consequential action from starting. Capability, data suitability, cost and business value belong in the decision too.
Ask the operator to demonstrate a normal task and an exception with the proposed instructions. Ask the maintainer how a failed connection, duplicate request or incorrect destination would be investigated. Confirm who can stop affected actions and who handles work while the workflow is unavailable.
Turn a missing answer into assigned work or a narrower launch scope. An authorised limited launch can provide useful operating evidence, but only within the agreed restrictions and response capacity. Keep the previous working version or manual alternative available and define when to return to it.
The separate implementation-planning guide covers early scope, action and ownership decisions. Use the prototype handoff guide to compare what a demonstration already tested with the remaining launch work.
What does maintenance after launch involve?
Maintenance means reviewing completed work, handling exceptions, repairing connections and revising the workflow when the business changes. Agree who judges quality, who implements technical fixes and who may approve a new job or broader access. More confidence in existing work does not itself authorise another workflow.
Set review and response arrangements from the actual consequences, change rate and workload. Record time spent checking, correcting and resolving cases so the business can assess the operating cost. Keep a reachable route for serious problems between scheduled reviews and a backup for absence.
When a provider, business rule, recipient or permission changes, decide which tests and operating records need updating before the affected action continues. Keep configuration changes distinct from action records so that a maintainer can connect a new problem to what changed.
For the detailed routine, use what AI agent maintenance actually involves. The implementation handover should identify who will use that routine and demonstrate how an unresolved finding becomes an assigned decision or repair.
Frequently asked questions
What does a real AI agent implementation involve?
A useful implementation plan covers the agreed job, permitted connections and actions, tests and operating responsibility. Define the deliverable, acceptance evidence and dependencies for each part. Work can overlap or return to an earlier decision when testing reveals a gap.
Why does AI agent scoping take so long?
Scoping can need time from the people who know the process and can authorise its consequences. Work through eligible requests, outputs, sources, approvals and exceptions with the partner. Technical exploration can happen alongside this; unresolved business decisions must be settled before their consequential actions run live.
What is the control layer in an AI agent?
It implements the permitted actions, access limits, approval and exception rules. The business authorises the scope and the partner demonstrates enforcement. Test a refused action, a changed proposal and unavailable review as well as a successful approval; documentation alone does not implement the boundary.
What is real-conditions testing for an AI agent?
It uses representative permitted inputs and agreed outcomes, including failures and excluded actions. Synthetic or suitably prepared examples can help alongside appropriate real cases. Verify the destination result and keep tests apart from uncontrolled live consequences where possible.
How long does a single-workflow AI agent implementation take?
Estimate remaining deliverables, access, process decisions, data preparation, testing and repairs after inspecting the starting point. Separate effort from waiting and ongoing operation. A universal number of weeks cannot describe every task or show whether a shorter project skipped work.
What makes an AI agent implementation fail?
Unclear value or scope, unsuitable data or capability, missing access, incorrect controls, failed handoffs and inadequate operating arrangements can each require correction or a stop decision. Investigate the actual findings rather than assuming a ranked cause or a fixed period when failure must appear.
What should a business own in an implementation, and what should the implementation partner own?
The business supplies process knowledge and authorises the intended job, consequences and success criteria. The partner advises on technical options, implements the agreed system and demonstrates results and restrictions. Assign decisions, access, tests, acceptance and ongoing support explicitly; work through unknowns together.
Notes
Sources accessed 15 October 2026. The phase map, estimating method and review questions are practical recommendations, not measured phase-duration or monthly maintenance benchmarks. Examples describe possible jobs, not client outcomes.
- Building effective agents. Anthropic; 19 December 2024; living page subsequently revised.
- Demystifying evals for AI agents. Anthropic; 9 January 2026.
