An agent in production is an operational system, not a project
Once an agent goes live, it stops being a project with a delivery date and becomes an operational system that requires the same ongoing discipline as any other production capability: monitoring, incident response, change control and a named owner. Treating go-live as the finish line is the most common reason agent programmes degrade quietly over time.
The shift in mindset required is similar to the one enterprises eventually made with integrations and automated workflows: initial delivery matters, but the governance function that runs afterward is where most of the risk, and most of the ongoing value, actually sits.
Topic and action scoping should be explicit and reviewed
Every agent should operate against an explicit, documented scope: the topics it is permitted to discuss and the actions it is permitted to take, both stated specifically rather than in general terms. This scope is not a one-time configuration decision; it should be reviewed on a regular cadence as the business changes what it expects the agent to handle.
Scope creep is a real risk in agent programmes, because it is technically easy to extend an agent's topics or actions incrementally, and each individual extension can look reasonable in isolation. Without a review process, an agent's effective authority can drift well beyond what was originally approved, with no single decision point where anyone assessed the cumulative risk.
A disciplined approach treats every proposed extension to topic or action scope as a change request subject to the same review rigor as the original deployment, not as a minor configuration tweak.
- Document topics and actions explicitly, not as broad categories
- Review scope on a set cadence, not only when someone raises a concern
- Treat scope extensions as governed change requests
Sharing-model inheritance must be verified, not assumed
An agent's data access should mirror the sharing and permission model already governing human users for the equivalent role, but this inheritance needs to be actively verified rather than assumed to be correct by default. Permission models in mature Salesforce orgs accumulate exceptions and legacy overrides over years, and an agent built against an outdated understanding of that model can end up with access nobody intended.
Periodic access reviews — the same discipline applied to human user permissions in a well-run security programme — should extend explicitly to agent identities. This includes verifying that any elevated permission granted temporarily for testing has been revoked before or shortly after go-live.
Human-in-the-loop thresholds need to be specific and testable
A governed agent operates with defined thresholds for when it acts autonomously and when it must pause for human approval. These thresholds should be specific enough to be testable: a transaction value above which approval is required, a category of request that always routes to a human, a confidence level below which the agent defers rather than guesses.
Vague thresholds — 'escalate anything unusual' — do not hold up in practice, because the agent has no reliable way to evaluate what counts as unusual. Specific, quantifiable thresholds can be tested directly, monitored over time, and adjusted deliberately as confidence in the agent's performance grows or as new failure modes are identified.
It is worth treating the threshold-setting exercise itself as a cross-functional decision involving the business owner, not a technical configuration left solely to the implementation team, because the risk tolerance being encoded is a business decision.
Audit trails are the foundation of accountability
Every action an agent takes, and the reasoning or data that led to it, should be logged in a way that is retrievable and reviewable well after the fact. This is not primarily a compliance formality; it is what allows the organisation to investigate a disputed outcome, identify the root cause of an error, and demonstrate to a regulator, an auditor or a customer exactly what happened and why.
The audit trail needs to capture more than the final answer given. It should capture what data the agent retrieved, what reasoning path it followed, and what action it ultimately took or proposed, so that a review after the fact can distinguish between the agent reasoning soundly from bad data and the agent reasoning unsoundly from good data. These require different remediation.
- Log the data retrieved, not only the final response
- Log the action taken or proposed, distinct from the conversation content
- Retain logs long enough to support dispute investigation and audit cycles
Evaluation and regression testing never stop
An agent's behaviour can shift over time as underlying models are updated, as data quality changes, or as the population of requests it receives evolves. Ongoing evaluation — sampling live interactions, scoring them against defined quality criteria, and comparing that score over time — is what catches this drift before it becomes visible to customers.
Regression testing matters equally: whenever the agent's configuration, underlying model version or connected data sources change, the organisation should re-run its evaluation scenario set to confirm existing behaviour has not degraded. This mirrors standard software regression discipline, applied to a system whose behaviour is probabilistic rather than fixed.
Organisations that skip this step tend to discover degradation only when a customer complaint or an internal audit surfaces it, well after the underlying cause has occurred, which makes root-causing the issue considerably harder.
Ownership after go-live has to be named, not implied
A recurring gap in agent programmes is the absence of a clearly named owner once the initial delivery team disbands. Someone specific needs to be accountable for the agent's ongoing performance, for reviewing escalations and audit findings, for approving scope changes, and for deciding when the agent should be paused or rolled back.
This ownership should sit with the business function the agent serves, supported by the technical team that built it, rather than defaulting entirely to IT. The business owner is best placed to judge whether the agent's behaviour aligns with what customers and the organisation actually need, while the technical team maintains the underlying capability.
The governance model is what makes scale possible
None of this guardrail structure exists to slow an agent programme down. It exists to make expansion safe: an organisation with clear scoping, verified permissions, tested thresholds, complete audit trails and ongoing evaluation can extend an agent's remit with confidence, because it has the evidence to know when that extension is warranted and when it is not.
Organisations without this structure tend to plateau early, not because the technology stops working, but because nobody is willing to expand an agent's authority without the evidence to justify it. Good governance, in this sense, is not a constraint on scale. It is the precondition for it.