Do you know which model version your newly inherited support agent is calling right now, and whose name is on the key that lets it write to Salesforce? If your team just took over an AI deployment someone else built, you should — and in most brownfield handovers, nobody on the receiving side can answer either question on day one.
That gap is the normal starting state. The original builder may be a departed engineer, a vendor whose statement of work ended, or a product team that shipped a pilot on Bedrock and then watched it quietly become load-bearing.
Operators ask us whether we work with companies that already have AI running in production. We do, and the work follows a consistent sequence: inventory, ownership transfer, baseline evaluation, and stabilization — in that order, and before anyone proposes a rebuild.
Taking over a production agent means making it legible before changing it. Map its dependencies, move credentials and on-call to your team, measure current behavior, then fix reliability gaps without a rewrite.
Why Inherited Agents Are Harder Than Greenfield Builds
A greenfield agent comes with its design intent attached, because the people operating it are the people who wrote it. An inherited agent arrives with only its behavior, and that behavior has usually drifted from whatever documentation survived the handover.
Prompts get edited in a console at 11 p.m. to fix a customer escalation. Tool definitions accumulate optional parameters that one downstream workflow now depends on, and a retry wrapper someone added in a hurry is the only reason a flaky Zendesk integration looks healthy.
What's more, the agent's users have adapted to its quirks. A support team may route certain tickets around the agent entirely, which means the failure rate in your dashboards understates the failure rate in reality.
This is why the first instinct — rebuild it properly — is usually wrong in the first month. After all, you cannot rebuild something correctly until you know what it currently does, including the behaviors nobody wrote down.
Inherited agents are harder because behavior drifts from documentation. Console prompt edits, undocumented retries, and user workarounds all shape production outcomes, and none of them appear in the original design.
Phase One: Inventory Everything the Agent Touches
The inventory is a map of the agent's blast radius. Keep in mind that you are cataloging what the system does in production, which is frequently different from what its repository suggests.
At minimum, the inventory should capture the following:
- Models and versions. Record every model ID the agent calls, including fallbacks, and whether each is pinned or floating on an alias. Note the provider's published deprecation date for each one.
- Prompts and system instructions. Export the prompts actually deployed, from the running artifact or the console, rather than trusting the copy in version control. Diff the two, because the delta is your first list of undocumented changes.
- Tools and write paths. List every tool in the registry, the system it calls, and whether it reads or writes. A tool that can update a HubSpot deal stage or close a ServiceNow ticket belongs on a separate, shorter list.
- Credentials and identity. Identify which IAM roles, API keys, and OAuth tokens the agent uses, and whose name is attached to each one. Personal access tokens tied to a departed employee are common and urgent.
- Data flows. Trace where inputs come from, where retrieved context lives (Pinecone, OpenSearch, Postgres with pgvector), and where outputs and logs land. Flag anything carrying PHI, PII, or contract terms.
- Spend. Pull 90 days of token and infrastructure cost by service. An inherited agent with no per-workflow cost attribution is the first candidate for a budget surprise.
Pull the inventory from evidence rather than interviews wherever you can. CloudTrail, Bedrock invocation logs, and API Gateway access logs will tell you what the agent called last Tuesday, while a former owner's memory tells you what they intended in March.
Once the map exists, rank each dependency by what breaks if it disappears. That ranking becomes the order of operations for everything that follows.
An agent inventory should list model IDs and deprecation dates, deployed prompts, every tool and its write paths, the credentials in use and their owners, data flows, and 90 days of spend by service.
Phase Two: Transfer Ownership Before You Change Anything
Ownership transfer is the step most teams skip, because it produces no visible improvement. However, every change you make before it happens is a change you cannot cleanly roll back or explain to an auditor.
Ownership has four parts, and all four need to land with the same team. Here's how they break down:
- Identity. Rotate credentials into service roles your team controls, scoped to the tools the inventory says the agent actually uses. Our guide to agent identity and access management covers the scoping pattern in detail.
- Deploy rights. Move the pipeline, infrastructure-as-code, and console access under your accounts. If prompts are edited in a console today, freeze that path and route every change through version control.
- Alerting and on-call. Repoint alarms, error notifications, and cost alerts to your rotation. An alert that still pages a vendor's shared inbox is an incident waiting to go unanswered.
- Documentation. Write the first runbook from what the inventory found, even if it is thin. Our approach to runbook capture treats that first draft as a living artifact that improves with every incident.
Rotating credentials on a live agent carries its own risk, so stage it. Issue the new role, run the agent against it in a lower environment or in shadow mode, confirm every tool call still succeeds, and only then revoke the old key.
Remember that the ownership record needs a business owner as well as a technical one. Someone outside the platform team has to be accountable for what the agent is allowed to decide, and that name belongs in your agent operating model before the first incident tests it.
Transfer ownership before changing behavior. Move identity, deploy rights, alerting, and runbooks to one team in the same window, so every later change is reversible, attributable, and covered by someone on call.
Phase Three: Baseline Evaluation on Real Traffic
The baseline answers a single question: how good is this agent today, measured the way you will measure it tomorrow? Without that number, every later argument about stabilizing versus rebuilding is opinion.
Start by sampling production traffic into an evaluation set — a few hundred real requests, stratified by workflow, with sensitive fields redacted. Then score the agent's actual outputs against criteria the business owner signs off on, using the methods in our agent evaluation framework.
Be aware that a single run is not a baseline. Hosted models frequently return different outputs for identical requests, and our research on inference reproducibility on models with no sampling controls shows why repeated runs are needed to separate real regressions from ordinary variance.
A useful baseline also covers more than output quality. It should include the following measurements:
- Task success rate. Score each workflow separately against the agreed rubric, because a blended number hides the workflow that is failing.
- Latency. Capture P50, P95, and P99, including time-to-first-token on streaming paths.
- Tool-call error rate. Count first-attempt failures as well as final failures, so you can see how often retries are masking a broken integration.
- Escalation rate. Track how often a human takes over, and check whether users are quietly bypassing the agent.
- Cost per completed task. Divide spend by successful outcomes, which is a sharper number than total monthly spend.
Those numbers become your first set of service-level objectives for the agent. As a result, they also become the comparison set for every future change, including any eventual rebuild.
A takeover baseline should measure task success per workflow, P50/P95/P99 latency, tool-call error and retry rates, human escalation rate, and cost per completed task, using repeated runs on sampled production traffic.
Phase Four: Stabilize in Place
Stabilization fixes the failure modes the inventory and baseline exposed, without changing what the agent is for. The goal is a system that behaves predictably under your operation, so that any later redesign starts from a known floor.
In most brownfield takeovers, the stabilization list looks broadly similar. Common items include:
- Pin the model. Replace floating aliases with explicit version IDs and put the retirement date on the calendar. An unpinned model is an unscheduled change, which is the core argument of our paper on why the model is a dependency with a retirement date.
- Make writes idempotent. Add idempotency keys to every tool that writes, so a retry cannot create a duplicate ticket or double-post a refund. Our post on agent idempotency walks through the key design.
- Bound retries. Replace unbounded retry loops with capped exponential backoff. Route terminal failures to an SQS dead-letter queue that someone actually reviews.
- Cap spend. Set per-workflow budgets and alarms so a prompt regression or a runaway loop shows up within hours. The controls in AI agent cost governance apply directly.
- Close the audit gap. Log each tool call with the request, the model version, the actor, and the outcome. Many inherited agents log the conversation and skip the actions, which is the half an auditor will ask for.
In fact, these fixes work best when retries, guardrails, and incident paths are treated as one reliability design surface for regulated AI. Patching them separately tends to produce a retry policy that fights the guardrail it was meant to protect.
Stabilization discipline: ship one change per release, inside a defined change window, and re-run the baseline after each one. If two fixes land together and the success rate moves, you will not know which fix moved it.
Stabilizing an inherited agent means pinning model versions, adding idempotency keys to write tools, bounding retries with a dead-letter queue, capping spend per workflow, and logging every tool call for audit.
Stabilize or Rebuild? Reading the Baseline
Once the agent is stable and measured, the rebuild question becomes answerable. In practice, the baseline points toward one of a few paths.
| Signal in the baseline | Likely path | Why |
|---|---|---|
| Success rate near target, failures clustered in two or three tools | Keep and harden | Targeted tool fixes close the gap at a fraction of rebuild cost |
| Quality acceptable, cost per task well above budget | Rework the model layer | Caching and routing changes can cut spend without touching workflow logic |
| Failures spread across workflows, prompts contradict each other | Phased rebuild | The architecture, rather than the tuning, is the constraint |
| Writes to regulated systems with no audit trail or access scoping | Stabilize controls first, then decide | Compliance exposure outranks quality questions |
The cost row deserves a closer look, because it is the one most often misread as a rebuild signal. Prompt caching and model routing on AWS Bedrock can often bring cost per task back in line while the agent's workflow logic stays exactly as it is.
Even when the answer is a rebuild, the stabilized original keeps serving traffic while the replacement runs in shadow mode against the same evaluation set. The cutover happens when the new system beats the baseline on the agreed numbers, which turns a migration argument into an ordinary decision under agent release management.
Rebuild an inherited agent only when the baseline shows failures spread across workflows or contradictory logic that tuning cannot fix. Run the replacement in shadow against the same evaluation set before cutover.
How Long Does a Takeover Take?
For a single agent with a handful of tools, the four phases typically run four to eight weeks. A multi-agent system spanning CRM, ticketing, and a data warehouse can take a full quarter, mostly because the inventory keeps finding dependencies.
A rough allocation for a single-agent takeover looks like this:
- Weeks 1–2: Inventory and ownership. Build the dependency map from logs, then stage credential rotation and repoint alerting. Freeze console prompt edits on the first day.
- Weeks 2–4: Baseline. Assemble the evaluation set, agree on the rubric with the business owner, and run repeated scoring passes. Publish the first SLOs.
- Weeks 4–8: Stabilization. Ship fixes one at a time in priority order, re-baselining after each. Close with a stabilize-or-rebuild recommendation backed by numbers.
Keep in mind that the phases overlap at the edges. That said, the order should not change: no behavioral changes until ownership has transferred, and no rebuild decision until the baseline exists.
Mistakes That Turn a Takeover Into an Incident
Most takeover incidents trace back to sequencing rather than skill. The patterns below recur across brownfield engagements:
- Upgrading the model on day one. A newer model changes outputs, tool-call formatting, and latency at once. Without a baseline, nobody can tell which change broke what.
- Revoking old credentials before testing new ones. The agent fails silently on its least-used tool, and the gap surfaces weeks later in a downstream report.
- Treating the repository as the source of truth. If the deployed prompt differs from the committed one, a routine redeploy rolls production back to a version nobody has run in months.
- Skipping the incident path. Taking over an agent means taking over its next outage, so your agent incident response plan needs your team's names in it before stabilization begins.
All of these share a root cause: changing the system before it is legible. The four-phase sequence exists to prevent exactly that.
Taking Ownership of an Agent Someone Else Built
An inherited agent is a production system with an unknown specification, and the safest way to own it is to make it measurable first. Inventory, ownership transfer, baseline evaluation, and stabilization give your team a defensible position before anyone commits budget to a rebuild.
If you're inheriting an agent from a departed team or an expiring vendor contract and want a second set of eyes on the handover, the team at iSimplifyMe builds and operates production agent systems across CRM, ticketing, and data warehouse environments every week through our AI agent operations practice. Reach out for a working session — we'll inventory what your agent touches, name the gaps you're about to inherit, and leave you with a sequenced stabilization plan.