What a 30-Day AI Agent Handover Should Actually Include
AI agent vendors often deploy and disappear, but a real handover ships four artifacts: owners, an eval harness, a runbook, and a compliance pack.
Most AI agent vendors call the project done when the agent goes live. Then they disappear, and you’re left with something that runs but nobody on your team can explain, maintain, or fix.
A real handover is different. It transfers ownership, not just access. This article covers the four artifacts every handover ships, the week-by-week timeline, and the acceptance criteria that tell you the vendor actually finished the job.
Why most AI agent handovers fail
A 30-day AI agent handover is a structured transfer period where the vendor moves full operational ownership of an agent to your internal team. The goal is straightforward: after day 30, your people run the agent without the vendor.
Most vendors skip the handover entirely. They ship an agent, confirm it works, and move on. You’re left with something that runs but no way to maintain it, monitor it, or fix it when something breaks.
A handover transfers ownership, not access. When the vendor disappears and nobody internally can explain how the agent decides, legal cannot verify the data handling and there is no escalation path for a bad output.
The failure modes look the same every time:
- No documented owner: The agent runs, but nobody internally is responsible for what it does.
- No eval harness: Your team has no way to measure if the agent gets worse over time.
- No runbook: When something breaks, nobody knows what to do.
- No compliance trail: Legal and audit teams cannot verify how data flows through the system.
The four artifacts every AI agent handover ships
Four deliverables separate a real handover from a vendor who just deployed something and left.
Documented owners
A written record naming the specific people accountable for the agent’s behavior, data, and business outcomes.
Not a team name. Not a Slack channel. Actual individuals with names.
Eval harness
A testing and monitoring system that measures agent performance continuously after handover. The eval harness is how you know the agent still works next month.
Runbook and rollback plan
Step-by-step instructions for operating the agent, handling errors, and reverting to a previous state when something goes wrong.
Compliance pack
Documentation proving the agent meets GDPR, EU data residency, and any other regulatory requirements relevant to your business.
Documented owners and the ownership matrix
Enterprise and compliance teams require named individuals. The ownership matrix maps each agent to four owner types, each with a distinct responsibility.
| Owner Type | Responsibility | Example Role |
|---|---|---|
| Agent Owner | Day-to-day operation and escalation | RevOps Manager |
| Data Owner | Data inputs, outputs, retention | Data Protection Officer |
| Business Owner | Budget, ROI, strategic decisions | VP Sales |
| Compliance Owner | Audit trail, regulatory sign-off | Legal Counsel |
Agent owner
The agent owner monitors the agent daily, receives alerts, and decides when to pause or adjust. After handover, the agent owner is the first line of defense when something looks off.
Data owner
The data owner is accountable for what data the agent accesses and where outputs are stored. GDPR requires this accountability to be explicit and documented.
Business owner
The business owner decides if the agent delivers value and has authority to expand or shut it down.
Compliance owner
The compliance owner confirms the agent meets internal policy and external regulation. The compliance owner reviews the compliance pack before sign-off.
The eval harness for production AI agents
An eval harness is a system that runs tests against agent outputs and scores performance over time. Without one, you have no way to detect when the agent starts producing worse outputs.
Think of the eval harness as continuous quality control. The agent worked on day one. The eval harness tells you if the agent still works on day 45.
Golden test cases
Golden test cases are a fixed set of inputs and expected outputs that the agent passes during handover. The vendor creates golden test cases from real production scenarios, not synthetic examples. If the agent fails a golden test case later, something changed.
Continuous evaluation on live traffic
Production traffic is the real test set. The eval harness samples live agent interactions and scores the interactions against quality criteria. Synthetic tests catch obvious failures. Live traffic catches the subtle ones.
Trajectory and session scoring
For agents that handle multi-step tasks (deal progression, onboarding sequences), the eval harness scores the entire session. A single good response in a bad sequence is still a failure. Trajectory scoring catches agents that win individual turns but lose the conversation.
Drift alerts and thresholds
Drift is when agent performance degrades over time because of changing data or model updates. The eval harness alerts owners when scores drop below acceptable thresholds. Without drift alerts, you find out the agent broke when a customer complains.
Runbooks, rollback, and access transfer
A runbook is a step-by-step operational guide for the agent. The runbook covers how to restart the agent, how to interpret logs, and when to escalate.
Rollback means your team can revert to the previous working version. If a model update breaks something, you go back to what worked.
Access transfer means credentials, API keys, and admin permissions move to your team. The vendor’s access is revoked. If the vendor still has the keys, you don’t own the agent.
A complete runbook typically includes:
- Start/stop procedures: How to pause the agent without losing data
- Log interpretation: What each log entry means and when to act
- Escalation matrix: Who to contact for which failure type
- Rollback trigger: Conditions under which to revert to the previous version
GDPR, EU data residency, and compliance artifacts
For DACH-region and broader European enterprise buyers, compliance documentation is not optional. The handover includes artifacts that legal and audit teams can review before signing off.
Data flow map
A data flow map is a visual diagram showing where data enters, where data is processed, where data is stored, and where data exits. GDPR Article 30 requires records of processing activities. The data flow map is how you create those records.
DPA and sub-processor list
A Data Processing Agreement (DPA) with the vendor plus a list of any third parties that touch the data. Enterprise legal teams will ask for the sub-processor list. Have it ready.
Retention and deletion policy
Documentation of how long agent data is kept and the process for deleting data. Zero-retention approaches, where data is deleted after delivery, simplify the retention policy considerably.
EU AI Act classification
For agents operating in the EU, documentation of the risk classification under the AI Act and the transparency obligations that follow from it. Two dates decide what belongs in the pack.
Since 2 August 2026, the Article 50 transparency obligations apply regardless of risk class: anyone interacting with an AI has to be told, and AI-generated content has to be marked machine-readably. Every customer-facing agent is in scope, so this is a hard item in every handover pack.
The high-risk obligations for stand-alone Annex III systems were deferred to 2 December 2027 by the Digital Omnibus, adopted at the end of June 2026. Most GTM agents are not high-risk anyway; we worked ten typical mid-market cases through the classification (auf Deutsch), but the classification itself, and the reasoning behind it, belongs in the pack under Article 6(3), which requires the assessment to be documented before deployment rather than on request.
The 30-day handover timeline week by week
What actually happens during the 30 days?
1. Week one: discovery and baseline
The vendor documents current workflows, identifies integration points, and establishes baseline metrics. The ownership matrix is drafted. By the end of week one, everyone knows who owns what.
2. Week two: build and shadow run
The agent is configured and runs in shadow mode. Shadow mode means the agent observes but does not act. The eval harness is set up with golden test cases. Shadow mode lets you see what the agent would do without any risk.
3. Week three: supervised go-live
The agent goes live with vendor supervision. Your team observes and begins handling alerts with vendor backup. Week three is where your team learns to operate the agent while the vendor is still available to answer questions.
4. Week four: transfer and sign-off
Full access transfer, runbook walkthrough, compliance pack delivery, and formal sign-off from all four owner types. By the end of week four, the vendor’s access is revoked and your team runs the agent independently.
How handover differs across GTM engines
Different agent types require different handover emphasis.
Outbound and demand engines
Outbound and demand engines have higher emphasis on deliverability monitoring and content voice verification. The eval harness focuses on reply quality and brand consistency. If the agent sounds wrong, your brand takes the hit.
Inbound and RevOps engines
Inbound and RevOps engines have higher emphasis on CRM data accuracy and routing logic. Compliance focus is on lead data handling and consent. Bad routing means leads go to the wrong rep or disappear entirely.
Deal and CS engines
Deal and CS engines have higher emphasis on multi-step trajectory scoring. Handover includes stakeholder mapping logic and health score calibration. A deal engine that wins individual calls but loses deals is worse than no agent at all.
Acceptance criteria that signal a real handover
Before the vendor can leave, all of the following are true:
- All four owners have signed the ownership matrix
- The eval harness has run for at least one week with no critical failures
- Your team has executed the runbook without vendor assistance
- Legal or the DPO has reviewed the compliance pack
- Access credentials are fully transferred with vendor access revoked
If any of the acceptance criteria are missing, the handover is incomplete.
What to demand from any AI agent vendor
How do you know if a vendor will actually do a real handover? Ask four questions before signing:
- “Who owns the agent after handover?” The vendor names customer roles, not vendor staff.
- “What eval harness do you ship?” The vendor describes continuous evaluation, not just deployment testing.
- “Where is our data processed?” The vendor confirms EU data residency if required.
- “What is in the compliance pack?” The vendor lists specific documents, not vague assurances.
If the answers are unclear, the handover will be too.
Own the output after Sondero leaves
At Sondero, every agent ships with documented owners, an eval harness, and a 30-day handover. Data is processed on German infrastructure with zero retention and deleted after delivery. GDPR documentation and EU data residency are ready to sign.
Your team owns the output after we leave. That is the point.
FAQs about the 30-day AI agent handover
How long does an AI agent handover take?
Thirty days is the minimum for enterprise deployments. Thirty days allows one full week of supervised production operation and time for all four owner types to complete sign-off.
Who signs off on the handover inside the customer team?
The four owners (agent, data, business, and compliance) each sign the ownership matrix. The business owner typically gives final approval.
What is the difference between an eval harness and a test suite?
A test suite runs before deployment to verify the agent works. An eval harness runs continuously in production to detect drift and degradation over time.
Can a team run the eval harness without engineering headcount?
Yes, if the vendor configures the harness during handover and provides a dashboard for non-technical owners to monitor scores and alerts.
What happens if an AI agent drifts after handover?
The eval harness alerts the agent owner when scores fall below thresholds. The runbook specifies whether to pause, rollback, or escalate.
Sources: AI Act Article 50, transparency obligations, Article 6, classification rules, Gibson Dunn on the Omnibus agreement and the new deadlines.
Strategy Call