Recent warnings from the Bank of England about autonomous AI agents have pushed a question up the agenda for financial firms: how does an institution intervene safely when an AI system starts behaving in ways nobody expected? Much of the debate has centred on kill switches, the mechanism for stopping a
system once it misbehaves. Cameron Etezadi, chief technology officer at LaunchDarkly, argues that the more useful question is how AI systems are monitored, adjusted and governed while they are running.
LaunchDarkly sells feature management and runtime control, so the argument has an obvious commercial alignment. The Fintech Times put that to Etezadi directly, along with the hardest version of the counter-argument: that a kill switch exists for the moment control has already failed. His written answers take both seriously.
Why the failure mode has changed
Etezadi’s starting point is that AI has changed what failure looks like. “The failure mode has changed,” he says. “Traditional software was largely deterministic: in theory, if you tested every use case, you could be confident it would behave as expected in production. AI systems are dynamic. The same question can produce a different answer each time, and behaviour can shift through model drift even when nobody has deployed new code.”
That variability, in his account, is not a defect to be engineered out. It is what makes the technology worth having. “Temperature settings effectively balance predictability against creativity: remove too much uncertainty and you risk creating an expensive version of traditional software; allow too much, and the system may behave in ways you did not intend.”
The consequence is that pre-production testing can no longer carry the whole burden of assurance, particularly as firms deploy AI in customer service, research and other workflows built on large volumes of unstructured data. “An airline chatbot should not start dispensing coding advice, and a research agent asked about Chaucer should not invent passages from Oscar Wilde,” he says. “Organisations therefore need runtime guardrails that continuously monitor outputs and steer behaviour while systems are live.”
The emergency brake and the brake pedal
Put to him that a kill switch is for the moment control has already failed, and that adjusting an agent at runtime does not unwind thousands of payments or trades it has already executed, Etezadi does not dismiss the hard stop. “Kill switches remain important, but they are the last line of defence, not the whole safety strategy,” he says. “Most failures in complex systems are not sudden or binary; signals usually begin to trend before the worst outcome occurs.”
His analogy is a car. “Consider a car which has an emergency brake. In normal traffic, you use the brake pedal proportionately. You slow down, adapt and continue making progress rather than stopping altogether.” Runtime controls, he says, “provide that same ability to intervene gradually and precisely”: an organisation might reduce an agent’s permissions, tighten thresholds, cap transaction volumes, reroute activity to a safer model or return a workflow to human review.
He gives a cost example. If demand for an AI customer-service system suddenly surges beyond its cost ceiling, “the business could switch to a cheaper model with slightly lower fidelity rather than shutting the service down and leaving customers unsupported”. For actions that cannot be reversed, his answer is about timing. “In payments or trading, where actions may be irreversible, the objective is to contain the blast radius early, not to stop the system after thousands of harmful actions.”
When the canary looks healthy
Gradual rollout is the other pillar of the runtime-control case, and it assumes the problem shows up in the canary. Etezadi concedes the limit. “Gradual rollouts reduce risk, but they mainly reveal common problems and early regressions,” he says. “A system can look perfectly healthy at one per cent exposure simply because it has not yet encountered the traffic level, market condition or combination of inputs that triggers the real failure.”
Asked for the most instructive example of a rollout that looked clean and was not, he points to capacity rather than model behaviour. “We have seen firsthand infrastructure that appeared stable being quickly overwhelmed by a new wave of connections, exceeding available capacity and causing an outage. The lesson is not that progressive delivery failed, but that rollout percentage cannot be the only control. “Teams, he says, need proactive monitoring and a feedback loop tied to the outcomes that matter, such as load, latency, cost, quality, errors and capacity, so that they can add resources, pause a rollout, reduce exposure
or compensate before the system fails. “Engineering is always a trade-off, and with software now so cheap to create, organisations must become better experimentalists. They must deploy enough to learn, evaluate the evidence, adjust quickly and repeat.”
What runtime control cannot do
The Bank of England’s concern is systemic: many firms, correlated behaviour and no single owner. A control that sits inside one institution’s own stack does not obviously reach that, and Etezadi says as much. “Runtime controls can reduce risk within an individual organisation, but they cannot resolve systemic financial risk by themselves. AI still requires human ownership and oversight.”
The difficulty he identifies is one of speed. “People cannot review decisions at the speed at which autonomous systems can make them, yet they still need confidence in the outcomes, visibility into what is happening and an auditable record of how the system behaved.” Runtime controls, in his description, are early-warning and steering mechanisms that identify when behaviour is moving outside agreed boundaries, so that an organisation can intervene before a circuit breaker is required. “If an outlet is becoming dangerously hot, you should detect the rising temperature and turn off the appliance before the breaker trips.
Runtime control is the temperature sensor; the circuit breaker is the last resort.”
For risks involving multiple firms, he says, “regulation and industry collaboration should set shared rules for accountability, oversight and when to intervene”.
Who is accountable
When an AI agent does something costly in production and a human set the flag that let it run, the question of who answers for it is live. Etezadi’s answer does not reach for the vendor. “The engineer, and, ultimately, the organisation deploying the system, must remain accountable for what it does,” he says. “;An AI agent may perform the action, but a person chose the model, defined its permissions, set the controls and allowed it to operate. That person therefore needs a credible way to understand and manage the downstream
implications of those decisions.”
Asked what would have to happen for him to accept that a hard stop, and not operational control, is the right answer for AI in financial services, Etezadi sets out the conditions rather than resisting the premise. “Hard stops still have an essential role. Not every process can be safely slowed, redirected or constrained, particularly when an agent has exceeded its authorised scope, the underlying data or model can no longer be trusted, or continued operation could cause immediate and irreversible harm.”
Runtime control, in his framing, is what stops a system reaching that point: reducing permissions, limiting exposure, changing models or moving decisions back to a person while the wider service continues to operate. He closes with a caveat. “Those controls are only as effective as the people who design them, the signals they monitor and the models interpreting those signals.”
Cameron Etezadi is chief technology officer at LaunchDarkly, which provides a runtime control layer for software releases, experimentation and AI agents in production.
The post Control AI Agents, Do Not Just Stop Them, Says LaunchDarkly CTO appeared first on The Fintech Times.
