Client
A UK-headquartered B2B SaaS platform serving mid-market and enterprise customers, expanding from a copilot-style assistant into an agent that takes autonomous action inside customer accounts
Sector
Technology & SaaS
Engagement
Agentic AI guardrail architecture, per-step action logging, human-approval gating and incident response readiness for an autonomous agent feature - multi-quarter programme.
What the client needed
The client's product had shipped a conversational AI assistant a year earlier and it had done well commercially, but the roadmap called for something more ambitious: an agent that could take real actions inside a customer's account on its own initiative, updating records, triggering workflows and calling third-party integrations, rather than only suggesting what a human should click next. Early prototypes worked in demos and worried everyone who saw them in a design review. Nobody could say with confidence what the agent had actually done after the fact beyond a final-outcome summary, there was no consistent way to stop a chain of actions mid-flight if something looked wrong, and customer-facing account changes were happening with the same trust level as a read-only chatbot reply, which several enterprise prospects flagged directly in security questionnaires as a blocker to signing. The client needed the autonomy the roadmap called for without gambling customer trust, and their existing security review process had no established pattern for approving a feature that behaved this differently from the rest of the product.
How we worked
- Mapped every action class the agent could take inside a customer account and classified each by blast radius, distinguishing reversible, low-impact actions from ones touching billing, permissions or data a customer couldn't easily undo.
- Built per-step action logging that records what the agent considered, what it chose, and why, not just the final outcome, so a support or security team can reconstruct any agent session after the fact.
- Designed a human-approval gate for the highest blast-radius action classes, letting the agent draft and queue the action but requiring an explicit customer or admin confirmation before it executes.
- Ran the agent inside a scoped execution sandbox with credentials limited to exactly the account and action classes a given task required, rather than a broad service account shared across all agent sessions.
- Built anomaly detection that flags sessions where the agent's action volume, sequence or target scope diverges sharply from typical patterns, surfacing them to the client's security team before a customer notices.
- Ran a phased rollout starting with a design-partner cohort on the lowest blast-radius action classes only, expanding scope only once logging, approval gating and anomaly detection had all been exercised against real usage.
Measured results
All figures verified with the client. Specific customer names and account-level detail withheld in line with our standard confidentiality terms.
- The client shipped the autonomous agent feature to its full customer base, including the enterprise accounts that had specifically flagged the earlier prototype as a blocker in security review.
- Every agent session became fully reconstructable step by step, closing the visibility gap that had stalled the original design reviews.
- Human-approval gating on high blast-radius actions has not slowed typical usage materially, since most everyday agent tasks fall into the pre-approved lower-impact classes.
- Anomaly detection has already flagged and paused a small number of agent sessions during rollout for review before any customer-visible impact occurred.
- The client's security team now has a repeatable review pattern for agentic features generally, rather than a one-off approval built for this launch alone, which is already being reused for a second agent capability in development.
- Sales reports the guardrail architecture, not just the agent's capability, has become a differentiator in enterprise procurement conversations, addressing objections that previously stalled deals.
"We could have shipped the capability a lot sooner if we'd been willing to launch without knowing exactly what the agent did in every session. The thing that actually got us past security review wasn't a smarter agent, it was being able to answer 'what did it do and why' for any single customer, on demand, in under a minute."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
The client's original copilot-style assistant had earned genuine customer trust because its blast radius was inherently limited: it could suggest, summarise and draft, but a human always clicked the button that actually changed something. Moving to an agent that clicked the button itself was a categorically different proposition, and the client's existing security review process, built around static feature launches with a fixed, auditable set of code paths, had no ready template for reviewing something that made different decisions on every run. Recent, well-publicised incidents involving autonomous agents acting with more reach than their operators intended had made the client's own security team, and several of its largest prospective customers, understandably cautious about exactly this category of feature, which shaped the engagement's central constraint from day one: ship real autonomy, but make every action the agent takes as visible and reversible as the review process demanded.
Timing added pressure. Competing products in the client's category were shipping agentic features on a similar timeline, and the commercial case for autonomy over a purely suggestive assistant was strong. The temptation to treat guardrails as a post-launch hardening exercise, ship the capability, add the controls once a customer asks, was real and we argued against it directly, because retrofitting approval gating onto an agent already trusted with unmediated account access is a much harder sell to a security team than building the gate in from the start.
Designing for blast radius, not for capability
The design decision that shaped everything downstream was classifying agent actions by blast radius rather than by feature area. A billing change and a display-preference update might sit in the same product module, but they do not belong in the same trust tier, and treating them identically would have meant either gating everything, which defeats the point of an autonomous agent, or gating nothing, which was the original problem. Once every action class had an explicit blast-radius rating, the approval-gating design followed naturally: low-impact, easily reversible actions execute immediately with full logging; anything touching billing, permissions, data deletion or external integrations queues for explicit confirmation before it runs.
Per-step logging turned out to matter as much as the gating itself. Early internal reviews kept surfacing the same question about the prototype, not "did the agent do the right thing" but "how would we ever know if it hadn't." Recording what the agent considered and why at each step, not just its final action, is what let the client's security team sign off with confidence, and it's the same capability that let support resolve customer questions about agent behaviour without escalating to engineering for a code-level investigation.
Rolling out without a blast-radius incident of our own
We pushed for a phased rollout starting with a design-partner cohort restricted to the lowest blast-radius action classes, expanding scope only as logging, approval gating and anomaly detection had each been exercised against genuine usage rather than test scenarios. That phasing cost calendar time the roadmap would have preferred not to spend, and it's the reason the anomaly detection layer had already caught and paused a handful of unusual sessions before the feature reached the full customer base, rather than after a customer noticed something wrong themselves.
Lessons learned
The first lesson was that "agentic" is not a single feature category with one review process; it is a spectrum of blast radius that needs its own classification before guardrails can be designed sensibly. Treating every agent action as equally risky, or equally safe, produces a worse outcome either way.
The second lesson was that per-step visibility, not just final-outcome correctness, is what earns a security team's trust in an autonomous system. A perfectly correct agent that cannot explain itself step by step is, from a governance standpoint, indistinguishable from a lucky one.
The third lesson was that building the approval and logging layer in from the start, even under roadmap pressure to ship faster, is materially cheaper than retrofitting it once an agent already has unmediated production access. The client's own security team said as much directly: the harder conversation would have been asking permission to add controls after the fact, not before.
If your organisation is building or planning an agentic AI feature and wants the autonomy without gambling the trust it took years to build, we would be glad to discuss what a guardrail programme like this might look like for you. Email sales@halfteck.com.