RichardHam.co.uk Blog

Tag: AI

  • When the Rules Become the Product

    When the Rules Become the Product

    This week kept returning to the same idea: the most useful engineering work is often the work that makes a system easier to trust.

    That does not always look exciting from the outside. It is not always a new feature, a flashy demo, or a dramatic redesign. More often it is the quieter work of making rules explicit, tightening feedback loops, removing ambiguity, and making the next decision easier than the last one.

    Across the repos I watched this week, that pattern showed up again and again. The common thread was less about adding novelty and more about turning guesswork into something people can actually operate.

    What happened

    1. hermes-mgmt kept pushing on cost, routing, and safety

    hermes-mgmt was the busiest repo in the set, and the signal was very clear: the platform is maturing by making its own guard rails stronger.

    A few of the issues were a good reminder that reliability starts with honesty. One thread called out how expensive large context windows become when autonomous loops keep calling them. Another flagged a provider routing problem where fallback behaviour was not matching the intent of the system. There was also a security issue around dependency CVEs and overly permissive local state handling, plus a series of local service defects that needed attention before they could become bigger problems.

    The pull requests told the same story from the implementation side. There were updates around shared spend visibility, stronger routing defaults, helper scripts for operator actions, secret-finding classifiers, carry guard hooks, resilient re-apply logic, memory activation, and better health checks. In plain English: this is the part of the work where a system stops relying on optimism and starts relying on policy.

    That matters because most production problems are not caused by one spectacular failure. They come from small inconsistencies that accumulate until the platform becomes harder to predict than it should be. The work in hermes-mgmt was a good example of the opposite: make the rules visible, make the fallback paths deliberate, and make the expensive behaviour harder to trigger by accident.

    2. ricambio-ai-roadmap moved product behaviour into the open

    The second big theme lived in ricambio-ai-roadmap, where the work on pilot2_email and the surrounding platform showed a lot more operational maturity than a casual observer might expect.

    There were fixes for transient IMAP failures, a fallback provider chain, and intent-based routing. There was also a 48-hour expiry policy, an in-app help section, and review-session documentation that makes the decision path much easier to follow later. At the same time, the live-platform review surfaced issues around basic-auth defaults, placeholder leakage risk, console labelling, and filter gaps.

    That mix is important. It means the project is no longer just building features; it is building a way to reason about those features.

    If a workflow is going to make decisions on behalf of a user, then the decision rules need to be legible. If a review finds a weak spot, the fix should not just patch the symptom. It should make the system easier to explain the next time somebody has to operate it.

    That is why the recent work here feels significant. It is not only improving the product. It is making the product harder to misunderstand.

    3. richardham-web-and-brand treated content and navigation as part of the system

    The web and brand repo had a very different surface area, but the same underlying pattern.

    There was work on missing sector pages, menu ordering, the AI stack page, homepage hero messaging, and proof-point content. There was also a rewrite of a blog post that had been flagged for confidential or internal detail. That kind of content cleanup is easy to underestimate, but it is exactly the sort of work that keeps a site coherent and credible.

    The best websites do not just look polished. They make it obvious where to go next.

    When navigation is clear, a visitor does not have to guess. When page structure is consistent, a service line is easier to understand. When internal detail is removed from public-facing copy, the story becomes more focused and more trustworthy. That is why I think of this sort of content work as part of the system, not a separate marketing task.

    It is also a useful reminder that design discipline and operational discipline are cousins. Both are about reducing friction. Both are about making the important thing easier to find. And both become more valuable as the system grows.

    4. Smaller repos kept reinforcing the same direction

    A few other repos pointed in the same direction even if they were not as noisy.

    dh-electrical-uk-website had redesign work and deploy tooling, which is a nice example of making a site feel more coherent and easier to ship.

    HamMediaLabs, lk-ai-roadmap, control-tower, and ai-cost-tracker all contributed to the broader picture as well: the more a platform matures, the more the useful work shifts toward clarity, repeatability, and control.

    That is a pattern I like because it is easy to miss in the moment. From far away, all of this can look like a list of unrelated tasks. Up close, it is really one story told in different repos: make the rules explicit, make the system observable, and make the next step easier to take.

    Key takeaways

    A few lessons stood out this week:

    • Routing should be policy, not folklore. If a system needs to choose between paths, the choice should be deliberate and explainable.
    • Security work belongs in the main workflow. Review findings, dependency checks, and permission problems are not side quests; they are part of keeping the platform honest.
    • Visibility is worth more than cleverness. Spend tracking, health checks, and honest dashboards make a system easier to run than vague confidence ever will.
    • Content operations matter. Navigation, structure, and public copy are part of the user experience and deserve the same discipline as the code behind them.
    • The best guard rail is a clear rule. The less people have to remember, the less likely the system is to depend on luck.

    Closing thought

    The strongest theme this week was not speed. It was trust.

    A system becomes easier to trust when the important choices are written down, the fallback paths are deliberate, and the rough edges are visible before they become incidents. That is true for routing policies, for security reviews, for website navigation, and for the way content moves from draft to publish.

    If you are trying to make an AI or automation workflow feel less like improvisation and more like operations, the next step usually is not more complexity. It is more clarity.

    And if that is the kind of cleanup you are wrestling with, get in touch.

  • When Systems Stop Relying on Guesswork

    A lot of avoidable operational pain comes from one simple source: somebody had to guess.

    They had to guess which model the workflow would choose. They had to guess whether a green dashboard meant the service was actually working. They had to guess how to recover something because the only real runbook lived in one person’s head. They had to guess which version of a draft was the right one to publish.

    That is a small sentence with expensive consequences.

    In my experience, many reliability problems are not caused by one dramatic bug. They come from layers of ambiguity that were tolerated because the system appeared to work often enough. The workflow usually picked the expected path. The dashboard was usually telling the truth. The operator usually remembered the recovery sequence. The content pipeline usually published the right version.

    Usually is not a safe operating model.

    Where the friction really sits

    The obvious failure is the outage. The more common failure is ambiguity that keeps making the whole stack harder to trust.

    Routing decisions

    If a system can choose between providers, models, or execution paths, then the decision logic needs to be durable and visible. Otherwise behaviour changes by accident.

    That is how teams end up with a platform that feels inconsistent even though each individual component is technically healthy. One person thinks the cheap path is the default. Another thinks the reliable path is. A third assumes the fallback only applies in a timeout case. None of that is a software problem at first. It is a policy problem.

    The fix is rarely glamorous. Write the rule. Keep it near the implementation. Make it obvious what happens first, what happens second, and what happens when the preferred path fails.

    Monitoring that tells the truth

    There is a big difference between “the process is running” and “the service is working”.

    A healthy-looking process table can still hide a broken dependency, a dead API path, a stale token, or an empty data plane. If the check only proves that something is listening on a port, it is not telling the operator what they actually need to know.

    Useful monitoring is usually the boring kind. Does the real workflow respond, with the right output, in the way the operator expects? Can someone tell whether a fallback fired? Can they see whether the service remained functionally correct rather than merely alive?

    If not, the dashboard is decoration.

    Recovery and repeatability

    A lot of infrastructure looks solid right up until someone else has to operate it.

    That is where repeatable recovery paths matter. Clear defaults. Known fallbacks. A documented sequence for fixing the obvious failure modes. The point is not to eliminate human judgement. The point is to stop every incident from turning into archaeology.

    Runbooks, checklists, and decision notes are not admin overhead for serious systems. They are part of the product if the product has to survive handover.

    Publishing discipline

    This applies to content as much as infrastructure.

    If the publishing path is fuzzy, you get duplicate posts, mismatched versions, archive drift, and copy that sounds assembled rather than written. That is not only a branding issue. It is the same operational problem wearing different clothes.

    The draft, the review step, the canonical source file, and the final publish target all need to be explicit. Otherwise the system eventually ships the wrong thing.

    Why AI multiplies the cost of ambiguity

    AI and automation raise the stakes because they convert vague process into machine-speed inconsistency.

    When a human operator is doing everything manually, weak process often shows up as wasted time. When workflows start routing, deciding, and acting on their own, the same vagueness becomes a production risk. The system can now repeat the wrong assumption quickly, quietly, and at scale.

    That is why I keep coming back to the same standard:

    • if it matters, write it down
    • if it repeats, make it reusable
    • if it can fail, define the fallback
    • if it is monitored, test the real behaviour
    • if it is published, keep one clear source of truth

    None of that is flashy. All of it matters.

    The useful kind of progress

    The best weeks are not always the dramatic ones.

    Sometimes the real progress is a tighter routing rule. A dashboard that finally reflects reality. A recovery path that no longer depends on memory. A publishing workflow that stops sending the wrong version into the public archive.

    That kind of work rarely looks exciting from the outside. It just makes the system calmer, safer, and easier to trust.

    And in practice, that is often the difference between something that demos well and something that survives production.

    If you want help turning AI or automation from a pile of moving parts into an operating model people can actually trust, start with AI & Automation Architecture or get in touch.

  • Why AI Workflows Need Audit Trails

    Why AI Workflows Need Audit Trails

    The conversation around AI has shifted. It is no longer just about drafting text or summarising meetings. More and more often, these systems are taking actions on live business processes.

    That is where the risk changes shape.

    A clever prompt can produce a good-looking result. It cannot tell you what happened after the fact if the output was wrong.

    The gap

    When a person makes a decision in a process, there is usually some trace of it. An email, a ticket, a sign-off, a log entry. With an AI system, that trace is often thin or missing.

    If the system updates the wrong record or sends the wrong message, the team is left with a result and very little explanation.

    What breaks without logs

    • You cannot reconstruct the sequence of events.
    • You cannot show who approved what.
    • You cannot improve the workflow with confidence.

    That is not just a debugging problem. It is an accountability problem.

    What a useful audit trail looks like

    At minimum, every execution should capture:

    • the input it received
    • the steps it took
    • the action it actually executed
    • the output it produced
    • the timestamp and identity of the run

    That is enough to answer the questions that matter later.

    The practical bit

    The tooling is already there. Structured logs, append-only storage, and reviewable traces are all enough to get started. The main thing is to design for visibility before the workflow is under pressure.

    If the system is allowed to act, it should also be required to explain itself.

  • The Hidden Cost Structure of Multi-Model AI

    The Hidden Cost Structure of Multi-Model AI

    You set a budget. You picked a model. You shipped the feature. Then the bill arrived.

    If you are running AI at scale across a product or platform, you have probably noticed that costs do not behave the way you expected. The per-token price looked reasonable in the dashboard. The monthly total did not.

    The problem is not that AI is expensive. The problem is that the cost structure is hidden.

    Why this matters now

    The shift from single-model to multi-model architectures is well underway. Most serious AI-powered products now route between several providers: a frontier model for complex reasoning, a cheaper one for classification and extraction, maybe a local model for high-volume, low-judgement work.

    That architecture is the right move. But it introduces a cost surface that almost nobody tracks properly. Different models have wildly different pricing. Some tasks genuinely need GPT-4o or Claude Sonnet. Most do not. And without visibility, you end up paying frontier prices for commodity work.

    The organisations that figure this out early will have a structural advantage. The ones that do not will burn budget and wonder why.

    What is really going on

    There are four hidden cost drivers in most multi-model setups. They compound each other.

    1. Token waste

    Every call to an LLM carries context: system prompts, conversation history, tool definitions, retrieved documents. In a multi-agent or multi-step workflow, that context grows at each hop. It is common to see workflows where 70 to 80 percent of the tokens sent are redundant or repeated across steps.

    At scale, that waste is not trivial. A workflow running 10,000 times a day with an average of 4,000 input tokens per call, where half of those tokens are unnecessary, can easily cost hundreds of pounds per month in tokens that contributed nothing to the output.

    2. Model mismatch

    This is the single biggest lever. Using Claude Sonnet for a task that Llama 3.2 handles just as well is a 10x cost difference for no quality gain. Using GPT-4o to classify support tickets is not just expensive, it is architecturally unnecessary.

    The pattern I see repeatedly: teams default to the most capable model available, then never revisit that decision once the feature is in production. The model that was right for prototyping is not necessarily right for day 10,000 of production.

    3. Lack of visibility

    Most AI billing is provider-level. You can see what you spent on OpenAI versus Anthropic versus a smaller provider. What you cannot see, without deliberate instrumentation, is the cost per workflow, per agent, per feature, or per team.

    That means nobody can answer basic questions. Which feature is the most expensive to run? Which team’s AI usage is growing fastest? Which workflow has the worst token-to-value ratio? Without per-workflow cost tracking, you are managing AI spend with a monthly credit card statement.

    4. API sprawl

    When multiple teams adopt AI independently, you end up with overlapping credentials, redundant integrations, and no centralised billing. One team uses OpenAI directly. Another wraps it in a different SDK. A third spins up a separate provider for a narrow use case. Each team optimises locally. Nobody optimises globally.

    This is not a technology problem. It is a governance gap, and it is expensive.

    What to do next

    The good news is that the solution pattern is well understood and does not require ripping out what you have already built.

    1. Route cheap tasks to free or local models.

    If a task does not require frontier reasoning, run it locally. Tools like Ollama make this practical for classification, extraction, summarisation, and other high-volume, low-judgement work. The cost difference is not marginal. It is the difference between paying per token and paying nothing beyond your compute.

    2. Reserve expensive models for high-judgement work.

    Define clear criteria for when a task warrants a frontier model. Complex reasoning, nuanced language generation, multi-step planning, and safety-critical decisions qualify. Everything else should default to the cheapest model that meets your quality bar.

    3. Track costs per workflow, not just per provider.

    Instrument your routing layer to log token usage and cost at the workflow or agent level. This does not require a complex platform. Even a lightweight middleware that tags each request with a workflow identifier and records input/output token counts will give you the visibility you need.

    4. Set budget alerts before you need them.

    Per-workflow budgets with hard and soft alerts let you catch runaway costs before they become line items in a board report. A soft alert at 70 percent of budget gives you time to investigate. A hard cap at 100 percent protects you from the unexpected.

    5. Audit your context.

    Review the prompts and context you are sending at each step of every workflow. Remove redundant system prompts, collapse repeated context, and set maximum token limits. This is the fastest way to reduce waste without changing any model choices.

    6. Centralise provider management.

    One set of credentials. One billing view. One team responsible for provider relationships and rate negotiations. This is not about slowing teams down. It is about making sure the organisation can see and manage what it is spending.

    Where Richard can help

    I work with technical leaders who are building AI-powered products and need the cost structure to be as well-designed as the architecture. That means routing strategies, cost tracking, and practical governance that does not get in the way of delivery.

    If multi-model cost management is on your roadmap, get in touch or review the relevant services.

  • The Case for Explicit Policies

    The Case for Explicit Policies

    Reliable systems do not emerge from good intentions. They emerge when the rules are explicit enough that another operator can understand what the system is supposed to do without reverse-engineering its behaviour from the wreckage.

    That sounds obvious, but it is still one of the most common gaps I see in automation and AI work. Teams build the workflow, connect the services, and get something working end to end. Then they leave the important decisions half-stated. Which provider is preferred? When should the fallback fire? What counts as a real health check? Which version of a process note is authoritative? The system may run, but the operating model is still fuzzy.

    The problem is not that people are careless. It is that policy work often looks less urgent than delivery work. Until something breaks, the invisible rule feels good enough.

    Where ambiguity shows up first

    The first place ambiguity appears is usually routing.

    A stack with multiple models, providers, queues, or execution paths always contains policy whether the team writes it down or not. If the preferred provider is too expensive for low-value tasks, that is policy. If one model is allowed for drafting but not for final output, that is policy. If a workflow should fall back only on timeout and not on quality failure, that is policy too.

    When none of that is written down clearly, people start inferring intent from whatever happened last.

    That is how teams end up with arguments that sound technical but are really operational:

    • “I thought the cheaper path was the default.”
    • “I assumed the fallback only applied during outages.”
    • “I didn’t realise this job was meant to stay on the private model.”
    • “I thought the dashboard alert meant the workflow had already rerouted.”

    None of those are bugs in isolation. They are symptoms of unstated policy.

    Why observability is part of policy

    The same issue appears in monitoring.

    A lot of dashboards tell you that a process is alive. That is not the same as proving the service is doing the right thing.

    For AI and automation systems, a truthful check usually needs to answer something more useful:

    • did the workflow complete the task it was supposed to complete?
    • did it use the intended path?
    • did it return data that looks structurally valid?
    • did the fallback stay dormant when the primary path was healthy?
    • can the operator see enough detail to explain the outcome afterward?

    If the check cannot answer those questions, the dashboard may still be visually tidy, but it is not giving the operator what they need.

    This is why I think observability should be treated as policy, not just instrumentation. The team has to decide what “working” actually means. Otherwise the monitoring layer simply reflects a vague assumption instead of a deliberate standard.

    Reuse is how policy survives handover

    The other quiet benefit of explicit policy is reuse.

    If a team has to rediscover the same routing rule, the same rollback sequence, or the same publishing checklist every time, then the policy is not really part of the system yet. It still lives in memory.

    That is expensive in a small team and dangerous in a growing one.

    Good reuse does not have to be elaborate. Often it is just a set of plain habits:

    • keep one canonical source of truth for important workflows
    • write fallback conditions near the implementation
    • keep short runbooks for the obvious failure modes
    • use the same naming and review patterns across similar jobs
    • record decisions before context evaporates

    None of that feels exciting while you are doing it. But it changes the quality of handover completely. A new operator no longer has to absorb the entire history of the stack before they can act safely.

    What explicit policy looks like in practice

    In practical terms, I look for a few simple signals.

    1. The preferred path is obvious

    The system should make it clear what happens first, what happens second, and under which conditions the fallback is allowed to take over.

    2. The checks reflect user reality

    A green dashboard should mean more than “something is listening on a port”. It should tell the operator whether the real job still works.

    3. Recovery paths exist before the incident

    If the first time a team documents the rollback sequence is during a failure, the policy work happened too late.

    4. Repeated patterns are actually reusable

    If the same kind of workflow appears three times, there should be a shared pattern instead of three slightly different tribal versions.

    Why this matters more with AI systems

    AI systems raise the cost of ambiguity because they turn a fuzzy rule into machine-speed inconsistency.

    In a manual process, unclear policy wastes time. In an automated one, it can silently change outputs, route work to the wrong provider, or create a trail that is too vague to audit later.

    That is why I think trustworthy AI is less about magic prompts and more about explicit operating rules.

    If the rules matter, write them down.

    If the outcome matters, check the real behaviour.

    If the workflow repeats, make it reusable.

    That does not make the system flashy. It makes it dependable.

    And in production, dependable usually wins.

    If you are building automation that needs to survive handover, escalation, and real operational scrutiny, the AI & Automation Architecture work is designed for exactly that. Or get in touch if you want a second pair of eyes on the operating model before the ambiguity becomes expensive.

  • Containment Patterns for Autonomous AI Agents

    Containment Patterns for Autonomous AI Agents

    You wouldn’t give a new employee the keys to every office, the admin password to every system, and a company credit card on day one. You’d onboard them gradually — scoped access, supervised actions, and a clear audit trail of what they did and why.

    Autonomous AI agents deserve the same treatment. Arguably more, because they can act faster, at greater scale, and with less inherent judgment than any human hire.

    Yet the pattern I see repeatedly is teams wiring agents directly into production systems with broad API keys, unrestricted network access, and no oversight. The agent works brilliantly — until it doesn’t. And when it goes wrong, nobody can explain what happened or why.

    This is a containment problem. And it’s solvable.

    Why containment matters now

    Autonomous agents are moving from demos into production. They’re reading emails, writing database records, triggering deployments, and calling external APIs. Each of those actions carries real business risk.

    The uncomfortable truth is that today’s agents are semi-trusted at best. Hallucinations aren’t just a chatbot annoyance — they’re an action an agent might take on a live system. A misinterpreted prompt can become a bulk delete. A confused tool call can cascade into an outage.

    Regulators are watching. The EU AI Act’s transparency and risk management requirements are already in force for high-risk systems. UK boards are starting to ask pointed questions about AI governance. If you can’t explain what your agents did and what guardrails were in place, you have a problem that no amount of prompt engineering will fix.

    The five containment patterns

    The patterns below are drawn from how we’d sandbox any untrusted or semi-trusted process — adapted for the specific risks that autonomous agents introduce. I’ve been implementing these in SentinelForge, a platform for running agents with strict governance, auditing, and observability.

    1. Process isolation

    Agents should run in their own isolated environment — a separate container or VM, not on a shared host alongside your production workloads.

    This means:

    • Dedicated runtime per agent or agent class, with its own filesystem and process namespace
    • Resource limits (CPU, memory, disk) so a runaway agent can’t starve other services
    • Immutable infrastructure — the agent’s environment is defined in code, rebuilt from scratch each run, and never patched in place

    If the agent is compromised or behaves unexpectedly, the blast radius stops at the container boundary.

    2. Network segmentation

    An agent should only be able to reach the endpoints it explicitly needs. Nothing more.

    In practice:

    • Egress filtering — whitelist approved domains and IP ranges; block everything else
    • No direct access to internal networks, metadata services (like cloud instance metadata endpoints), or other agents’ environments
    • DNS-level controls to prevent DNS exfiltration or calls to unexpected services

    Think of it like a corporate network with VLANs. The marketing intern doesn’t need access to the finance database. Your agent doesn’t need access to the public internet.

    3. Credential scoping

    This is where most agent deployments go wrong. A single long-lived API key with broad permissions is the agent equivalent of a master key.

    Instead:

    • Time-limited tokens — credentials that expire after a task or session, not months
    • Minimum privilege — if the agent only needs to read from a database, it doesn’t get write access
    • Brokered access — credentials are injected at runtime by a secrets manager, never stored in the agent’s environment or prompt
    • Per-task credentials — different actions get different tokens, so a compromise in one area doesn’t cascade

    4. Output validation

    Before an agent’s action hits a real system, it should pass through a validation layer.

    This means:

    • Schema validation — does the agent’s requested action match an expected structure?
    • Policy checks — is this action allowed given the current context, user, and risk level?
    • Human-in-the-loop gates for high-risk actions (bulk operations, deletions, external communications)
    • Dry-run capability — the ability to simulate what the agent would do before it does it

    This isn’t about slowing agents down. It’s about making sure the action that executes is the action you intended.

    5. Audit logging

    Every action an agent takes should be recorded in a tamper-evident log that’s separate from the agent itself.

    Capture:

    • What the agent did (the action, the target, the parameters)
    • Why it did it (the prompt, the reasoning chain, the tool call context)
    • When it happened (with reliable, centralised timestamps)
    • What the outcome was (success, failure, validation result)

    This log is your forensic trail when something goes wrong. It’s also your evidence for compliance, board reporting, and continuous improvement.

    A practical containment checklist

    If you’re deploying autonomous agents today, here’s a quick audit:

    • [ ] Each agent runs in an isolated container or VM with resource limits
    • [ ] Network egress is restricted to an explicit allowlist
    • [ ] No long-lived credentials — tokens are time-limited and minimum-privilege
    • [ ] Credentials are brokered at runtime, never hardcoded or stored in prompts
    • [ ] Agent actions pass through a validation or policy layer before execution
    • [ ] High-risk actions require human approval
    • [ ] All actions are logged to a tamper-evident, centralised audit trail
    • [ ] Logs are reviewed regularly, not just when something goes wrong

    If you can’t check at least six of those boxes, your agents are running with more freedom than most of your employees.

    The principle is simple

    Autonomous agents are powerful. That power needs guardrails — not because the technology is malicious, but because it’s fast, scalable, and imperfect. The same qualities that make agents valuable are the qualities that make containment essential.

    The patterns aren’t exotic. They’re the same ones we’ve used for decades to manage untrusted code, third-party integrations, and new employees. The difference is that agents can act at machine speed, so your guardrails need to be just as fast and just as automated.

    This is the problem I’m working on with SentinelForge — making these patterns practical and deployable, not just theoretical.

    If agent containment is on your roadmap, get in touch or take a look at the projects I’m building in this space.

  • Building a Secure Agent Control Plane With Observability From Day One

    Building a Secure Agent Control Plane With Observability From Day One

    AI agents are being connected to real business systems at pace. Email inboxes. CRM records. Finance platforms. Document stores. In many organisations, agents now read, write, and decide across these systems — not as a pilot, but as operational infrastructure.

    The problem is that the operational infrastructure around those agents has not kept pace. Teams connect agents to sensitive systems the same way they would connect a chatbot: authenticate, test, deploy. There is no logging layer, no approval gate, no cost tracking, no failure recovery. The agent works until it does not, and when it breaks, nobody knows why.

    The agents themselves are often well-designed. The prompts are thoughtful. The integrations function. But there is no control plane — no layer between the agent and the systems it touches that handles authorisation, logging, rate limiting, approval, and monitoring. Without one, you are running production workloads with no operations team.

    What an Agent Control Plane Actually Is

    An agent control plane is the operational layer that sits between your AI agents and the systems they interact with. It is not a single tool. It is a set of components that collectively ensure agents act safely, their actions are visible, and failures are recoverable.

    Think of it the way you would think about any production system. A web application has authentication, logging, rate limiting, monitoring, and alerting. A database has access controls, backup procedures, and performance monitoring. An agent that reads client records, sends emails, and updates financial data needs the same — arguably more, because its behaviour is less deterministic than a traditional application.

    The control plane answers a set of questions that every production system must answer: Who is allowed to do what? What actually happened? How much did it cost? What do we do when it fails? And can we prove all of this to an auditor, a regulator, or a board?

    The Six Components You Need

    Authentication broker. Agents need credentials to access systems, but those credentials should not live inside the agent or its prompt. A central broker issues scoped, time-limited tokens with minimum permissions. When the token expires, access stops. This is service account management applied to agents.

    Audit logger. Every agent action must be logged in a structured, tamper-evident format. Not just the final output — the full chain: what the agent was asked, which tools it called, what decisions it made, what it executed, and what it returned. Teams log the input and output but miss the intermediate steps. When an agent takes an unexpected action, you need to trace the reasoning that led to it.

    Approval workflow. Not every action should be autonomous. A control plane defines which actions require human approval before execution. Sending an internal summary might be automated. Sending a client-facing email or modifying a financial record should require sign-off. The approval gate sits in the control plane, not in the agent’s prompt — a prompt is a request, not an enforcement mechanism.

    Observability. Tools like Langfuse are designed for this. Observability for agents means tracking execution traces, token usage, latency, error rates, and cost per execution. It means answering questions like: which workflow failed most often last week? Which agent is consuming the most tokens? Is the error rate increasing?

    Cost tracking. Agentic AI is not free. Every model call, every tool invocation, every token consumed has a cost. Without cost tracking per agent, per workflow, and per execution, you cannot budget, optimise, or identify waste.

    Failure recovery. Agents fail. Models time out. APIs return errors. A control plane defines what happens: does it retry? Escalate to a human? Roll back? Without explicit failure recovery, a failed agent either silently drops the task or retries indefinitely, burning tokens and creating duplicate actions.

    A Concrete Example

    Consider an n8n workflow that processes incoming client data: it reads a form submission, enriches the record with data from an external API, updates the CRM, and sends a confirmation email.

    Without a control plane, this workflow runs with a static API key, no logging beyond n8n’s default execution history, no approval gate for the email send, and no cost tracking. If the CRM API returns an error, the workflow fails silently. If the agent sends a confirmation email to the wrong address because the form data was malformed, there is no record of what data it saw or why it made that decision.

    With a control plane, the same workflow runs with a scoped token from the authentication broker, full execution tracing through Langfuse, an approval gate that holds the email send when the confidence score is below a threshold, and automatic retry with escalation on failure. Every execution is logged with its full decision chain. Cost per execution is tracked and surfaced on a dashboard.

    The workflow is the same. The operational posture is completely different.

    Why From Day One Matters

    Retrofitting observability and security into a live system is significantly more expensive than building it in from the start. Not just in money — in time, risk, and organisational friction.

    When you add a control plane after agents are already in production, you must modify every existing workflow to route through the new layer, backfill logs for actions that already happened, and negotiate with teams accustomed to unfettered agent access. In practice, this work costs roughly three times what it would have cost to build the control plane first — before accounting for the risk exposure during the period agents ran without controls.

    Building it from day one means the control plane is part of the deployment process. Every new agent is onboarded through it. Every execution is logged from the first run. Every cost is tracked from the first token. No migration, no retrofitting, no gap.

    What to Do Next

    If you are running agentic AI in your organisation — or planning to — here is where to start.

    1. Inventory your agents. List every agent, workflow, and automated process that takes action on a business system. Include what systems it accesses, what credentials it uses, and what actions it can perform. You cannot secure what you have not catalogued.

    2. Add structured logging. For every agent execution, log the input, the decision chain, the action taken, the output, and the timestamp. Use a consistent schema. Send these logs to a central, append-only store. If you are using n8n, configure each node to log its input and output. Integrate a tracing tool like Langfuse from the start.

    3. Implement approval gates for high-risk actions. Define which actions require human sign-off: anything client-facing, anything that modifies financial data, anything that changes system configuration. Build the approval gate into the control plane, not into the agent’s prompt.

    4. Set up observability. Deploy an observability layer that tracks execution traces, error rates, token usage, and cost per workflow. Build dashboards. Set alerts for anomalies — sudden cost increases, rising error rates, unusual execution patterns.

    5. Define failure recovery. For every workflow, document what happens on failure. Retry logic, escalation paths, rollback procedures. Test these before you need them.

    The organisations that will extract the most value from agentic AI are not the ones that move fastest. They are the ones that move safely — with the infrastructure to observe, control, and recover from the inevitable failures.

    If you are building agentic systems and need help designing the control plane, observability, and security architecture around them, the AI & Automation Architecture service covers exactly this. For examples of what this looks like in practice, see recent projects.

  • Building a Secure Agent Control Plane With Observability From Day One

    Building a Secure Agent Control Plane With Observability From Day One

    AI agents are being connected to real business systems at pace. Email inboxes. CRM records. Finance platforms. Document stores. In many organisations, agents now read, write, and decide across these systems — not as a pilot, but as operational infrastructure.

    The problem is that the operational infrastructure around those agents has not kept pace. Teams connect agents to sensitive systems the same way they would connect a chatbot: authenticate, test, deploy. There is no logging layer, no approval gate, no cost tracking, no failure recovery. The agent works until it does not, and when it breaks, nobody knows why.

    The agents themselves are often well-designed. The prompts are thoughtful. The integrations function. But there is no control plane — no layer between the agent and the systems it touches that handles authorisation, logging, rate limiting, approval, and monitoring. Without one, you are running production workloads with no operations team.

    What an Agent Control Plane Actually Is

    An agent control plane is the operational layer that sits between your AI agents and the systems they interact with. It is not a single tool. It is a set of components that collectively ensure agents act safely, their actions are visible, and failures are recoverable.

    Think of it the way you would think about any production system. A web application has authentication, logging, rate limiting, monitoring, and alerting. A database has access controls, backup procedures, and performance monitoring. An agent that reads client records, sends emails, and updates financial data needs the same — arguably more, because its behaviour is less deterministic than a traditional application.

    The control plane answers a set of questions that every production system must answer: Who is allowed to do what? What actually happened? How much did it cost? What do we do when it fails? And can we prove all of this to an auditor, a regulator, or a board?

    The Six Components You Need

    Authentication broker. Agents need credentials to access systems, but those credentials should not live inside the agent or its prompt. A central broker issues scoped, time-limited tokens with minimum permissions. When the token expires, access stops. This is service account management applied to agents.

    Audit logger. Every agent action must be logged in a structured, tamper-evident format. Not just the final output — the full chain: what the agent was asked, which tools it called, what decisions it made, what it executed, and what it returned. Teams log the input and output but miss the intermediate steps. When an agent takes an unexpected action, you need to trace the reasoning that led to it.

    Approval workflow. Not every action should be autonomous. A control plane defines which actions require human approval before execution. Sending an internal summary might be automated. Sending a client-facing email or modifying a financial record should require sign-off. The approval gate sits in the control plane, not in the agent’s prompt — a prompt is a request, not an enforcement mechanism.

    Observability. Tools like Langfuse are designed for this. Observability for agents means tracking execution traces, token usage, latency, error rates, and cost per execution. It means answering questions like: which workflow failed most often last week? Which agent is consuming the most tokens? Is the error rate increasing?

    Cost tracking. Agentic AI is not free. Every model call, every tool invocation, every token consumed has a cost. Without cost tracking per agent, per workflow, and per execution, you cannot budget, optimise, or identify waste.

    Failure recovery. Agents fail. Models time out. APIs return errors. A control plane defines what happens: does it retry? Escalate to a human? Roll back? Without explicit failure recovery, a failed agent either silently drops the task or retries indefinitely, burning tokens and creating duplicate actions.

    A Concrete Example

    Consider an n8n workflow that processes incoming client data: it reads a form submission, enriches the record with data from an external API, updates the CRM, and sends a confirmation email.

    Without a control plane, this workflow runs with a static API key, no logging beyond n8n’s default execution history, no approval gate for the email send, and no cost tracking. If the CRM API returns an error, the workflow fails silently. If the agent sends a confirmation email to the wrong address because the form data was malformed, there is no record of what data it saw or why it made that decision.

    With a control plane, the same workflow runs with a scoped token from the authentication broker, full execution tracing through Langfuse, an approval gate that holds the email send when the confidence score is below a threshold, and automatic retry with escalation on failure. Every execution is logged with its full decision chain. Cost per execution is tracked and surfaced on a dashboard.

    The workflow is the same. The operational posture is completely different.

    Why From Day One Matters

    Retrofitting observability and security into a live system is significantly more expensive than building it in from the start. Not just in money — in time, risk, and organisational friction.

    When you add a control plane after agents are already in production, you must modify every existing workflow to route through the new layer, backfill logs for actions that already happened, and negotiate with teams accustomed to unfettered agent access. In practice, this work costs roughly three times what it would have cost to build the control plane first — before accounting for the risk exposure during the period agents ran without controls.

    Building it from day one means the control plane is part of the deployment process. Every new agent is onboarded through it. Every execution is logged from the first run. Every cost is tracked from the first token. No migration, no retrofitting, no gap.

    What to Do Next

    If you are running agentic AI in your organisation — or planning to — here is where to start.

    1. Inventory your agents. List every agent, workflow, and automated process that takes action on a business system. Include what systems it accesses, what credentials it uses, and what actions it can perform. You cannot secure what you have not catalogued.

    2. Add structured logging. For every agent execution, log the input, the decision chain, the action taken, the output, and the timestamp. Use a consistent schema. Send these logs to a central, append-only store. If you are using n8n, configure each node to log its input and output. Integrate a tracing tool like Langfuse from the start.

    3. Implement approval gates for high-risk actions. Define which actions require human sign-off: anything client-facing, anything that modifies financial data, anything that changes system configuration. Build the approval gate into the control plane, not into the agent’s prompt.

    4. Set up observability. Deploy an observability layer that tracks execution traces, error rates, token usage, and cost per workflow. Build dashboards. Set alerts for anomalies — sudden cost increases, rising error rates, unusual execution patterns.

    5. Define failure recovery. For every workflow, document what happens on failure. Retry logic, escalation paths, rollback procedures. Test these before you need them.

    The organisations that will extract the most value from agentic AI are not the ones that move fastest. They are the ones that move safely — with the infrastructure to observe, control, and recover from the inevitable failures.

    If you are building agentic systems and need help designing the control plane, observability, and security architecture around them, the AI & Automation Architecture service covers exactly this. For examples of what this looks like in practice, see recent projects.

  • Building a Secure Agent Control Plane With Observability From Day One

    Building a Secure Agent Control Plane With Observability From Day One

    AI agents are being connected to real business systems at pace. Email inboxes. CRM records. Finance platforms. Document stores. In many organisations, agents now read, write, and decide across these systems — not as a pilot, but as operational infrastructure.

    The problem is that the operational infrastructure around those agents has not kept pace. Teams connect agents to sensitive systems the same way they would connect a chatbot: authenticate, test, deploy. There is no logging layer, no approval gate, no cost tracking, no failure recovery. The agent works until it does not, and when it breaks, nobody knows why.

    The agents themselves are often well-designed. The prompts are thoughtful. The integrations function. But there is no control plane — no layer between the agent and the systems it touches that handles authorisation, logging, rate limiting, approval, and monitoring. Without one, you are running production workloads with no operations team.

    What an Agent Control Plane Actually Is

    An agent control plane is the operational layer that sits between your AI agents and the systems they interact with. It is not a single tool. It is a set of components that collectively ensure agents act safely, their actions are visible, and failures are recoverable.

    Think of it the way you would think about any production system. A web application has authentication, logging, rate limiting, monitoring, and alerting. A database has access controls, backup procedures, and performance monitoring. An agent that reads client records, sends emails, and updates financial data needs the same — arguably more, because its behaviour is less deterministic than a traditional application.

    The control plane answers a set of questions that every production system must answer: Who is allowed to do what? What actually happened? How much did it cost? What do we do when it fails? And can we prove all of this to an auditor, a regulator, or a board?

    The Six Components You Need

    Authentication broker. Agents need credentials to access systems, but those credentials should not live inside the agent or its prompt. A central broker issues scoped, time-limited tokens with minimum permissions. When the token expires, access stops. This is service account management applied to agents.

    Audit logger. Every agent action must be logged in a structured, tamper-evident format. Not just the final output — the full chain: what the agent was asked, which tools it called, what decisions it made, what it executed, and what it returned. Teams log the input and output but miss the intermediate steps. When an agent takes an unexpected action, you need to trace the reasoning that led to it.

    Approval workflow. Not every action should be autonomous. A control plane defines which actions require human approval before execution. Sending an internal summary might be automated. Sending a client-facing email or modifying a financial record should require sign-off. The approval gate sits in the control plane, not in the agent’s prompt — a prompt is a request, not an enforcement mechanism.

    Observability. Tools like Langfuse are designed for this. Observability for agents means tracking execution traces, token usage, latency, error rates, and cost per execution. It means answering questions like: which workflow failed most often last week? Which agent is consuming the most tokens? Is the error rate increasing?

    Cost tracking. Agentic AI is not free. Every model call, every tool invocation, every token consumed has a cost. Without cost tracking per agent, per workflow, and per execution, you cannot budget, optimise, or identify waste.

    Failure recovery. Agents fail. Models time out. APIs return errors. A control plane defines what happens: does it retry? Escalate to a human? Roll back? Without explicit failure recovery, a failed agent either silently drops the task or retries indefinitely, burning tokens and creating duplicate actions.

    A Concrete Example

    Consider an n8n workflow that processes incoming client data: it reads a form submission, enriches the record with data from an external API, updates the CRM, and sends a confirmation email.

    Without a control plane, this workflow runs with a static API key, no logging beyond n8n’s default execution history, no approval gate for the email send, and no cost tracking. If the CRM API returns an error, the workflow fails silently. If the agent sends a confirmation email to the wrong address because the form data was malformed, there is no record of what data it saw or why it made that decision.

    With a control plane, the same workflow runs with a scoped token from the authentication broker, full execution tracing through Langfuse, an approval gate that holds the email send when the confidence score is below a threshold, and automatic retry with escalation on failure. Every execution is logged with its full decision chain. Cost per execution is tracked and surfaced on a dashboard.

    The workflow is the same. The operational posture is completely different.

    Why From Day One Matters

    Retrofitting observability and security into a live system is significantly more expensive than building it in from the start. Not just in money — in time, risk, and organisational friction.

    When you add a control plane after agents are already in production, you must modify every existing workflow to route through the new layer, backfill logs for actions that already happened, and negotiate with teams accustomed to unfettered agent access. In practice, this work costs roughly three times what it would have cost to build the control plane first — before accounting for the risk exposure during the period agents ran without controls.

    Building it from day one means the control plane is part of the deployment process. Every new agent is onboarded through it. Every execution is logged from the first run. Every cost is tracked from the first token. No migration, no retrofitting, no gap.

    What to Do Next

    If you are running agentic AI in your organisation — or planning to — here is where to start.

    1. Inventory your agents. List every agent, workflow, and automated process that takes action on a business system. Include what systems it accesses, what credentials it uses, and what actions it can perform. You cannot secure what you have not catalogued.

    2. Add structured logging. For every agent execution, log the input, the decision chain, the action taken, the output, and the timestamp. Use a consistent schema. Send these logs to a central, append-only store. If you are using n8n, configure each node to log its input and output. Integrate a tracing tool like Langfuse from the start.

    3. Implement approval gates for high-risk actions. Define which actions require human sign-off: anything client-facing, anything that modifies financial data, anything that changes system configuration. Build the approval gate into the control plane, not into the agent’s prompt.

    4. Set up observability. Deploy an observability layer that tracks execution traces, error rates, token usage, and cost per workflow. Build dashboards. Set alerts for anomalies — sudden cost increases, rising error rates, unusual execution patterns.

    5. Define failure recovery. For every workflow, document what happens on failure. Retry logic, escalation paths, rollback procedures. Test these before you need them.

    The organisations that will extract the most value from agentic AI are not the ones that move fastest. They are the ones that move safely — with the infrastructure to observe, control, and recover from the inevitable failures.

    If you are building agentic systems and need help designing the control plane, observability, and security architecture around them, the AI & Automation Architecture service covers exactly this. For examples of what this looks like in practice, see recent projects.

  • Building a Secure Agent Control Plane With Observability From Day One

    Building a Secure Agent Control Plane With Observability From Day One

    AI agents are being connected to real business systems at pace. Email inboxes. CRM records. Finance platforms. Document stores. In many organisations, agents now read, write, and decide across these systems — not as a pilot, but as operational infrastructure.

    The problem is that the operational infrastructure around those agents has not kept pace. Teams connect agents to sensitive systems the same way they would connect a chatbot: authenticate, test, deploy. There is no logging layer, no approval gate, no cost tracking, no failure recovery. The agent works until it does not, and when it breaks, nobody knows why.

    The agents themselves are often well-designed. The prompts are thoughtful. The integrations function. But there is no control plane — no layer between the agent and the systems it touches that handles authorisation, logging, rate limiting, approval, and monitoring. Without one, you are running production workloads with no operations team.

    What an Agent Control Plane Actually Is

    An agent control plane is the operational layer that sits between your AI agents and the systems they interact with. It is not a single tool. It is a set of components that collectively ensure agents act safely, their actions are visible, and failures are recoverable.

    Think of it the way you would think about any production system. A web application has authentication, logging, rate limiting, monitoring, and alerting. A database has access controls, backup procedures, and performance monitoring. An agent that reads client records, sends emails, and updates financial data needs the same — arguably more, because its behaviour is less deterministic than a traditional application.

    The control plane answers a set of questions that every production system must answer: Who is allowed to do what? What actually happened? How much did it cost? What do we do when it fails? And can we prove all of this to an auditor, a regulator, or a board?

    The Six Components You Need

    Authentication broker. Agents need credentials to access systems, but those credentials should not live inside the agent or its prompt. A central broker issues scoped, time-limited tokens with minimum permissions. When the token expires, access stops. This is service account management applied to agents.

    Audit logger. Every agent action must be logged in a structured, tamper-evident format. Not just the final output — the full chain: what the agent was asked, which tools it called, what decisions it made, what it executed, and what it returned. Teams log the input and output but miss the intermediate steps. When an agent takes an unexpected action, you need to trace the reasoning that led to it.

    Approval workflow. Not every action should be autonomous. A control plane defines which actions require human approval before execution. Sending an internal summary might be automated. Sending a client-facing email or modifying a financial record should require sign-off. The approval gate sits in the control plane, not in the agent’s prompt — a prompt is a request, not an enforcement mechanism.

    Observability. Tools like Langfuse are designed for this. Observability for agents means tracking execution traces, token usage, latency, error rates, and cost per execution. It means answering questions like: which workflow failed most often last week? Which agent is consuming the most tokens? Is the error rate increasing?

    Cost tracking. Agentic AI is not free. Every model call, every tool invocation, every token consumed has a cost. Without cost tracking per agent, per workflow, and per execution, you cannot budget, optimise, or identify waste.

    Failure recovery. Agents fail. Models time out. APIs return errors. A control plane defines what happens: does it retry? Escalate to a human? Roll back? Without explicit failure recovery, a failed agent either silently drops the task or retries indefinitely, burning tokens and creating duplicate actions.

    A Concrete Example

    Consider an n8n workflow that processes incoming client data: it reads a form submission, enriches the record with data from an external API, updates the CRM, and sends a confirmation email.

    Without a control plane, this workflow runs with a static API key, no logging beyond n8n’s default execution history, no approval gate for the email send, and no cost tracking. If the CRM API returns an error, the workflow fails silently. If the agent sends a confirmation email to the wrong address because the form data was malformed, there is no record of what data it saw or why it made that decision.

    With a control plane, the same workflow runs with a scoped token from the authentication broker, full execution tracing through Langfuse, an approval gate that holds the email send when the confidence score is below a threshold, and automatic retry with escalation on failure. Every execution is logged with its full decision chain. Cost per execution is tracked and surfaced on a dashboard.

    The workflow is the same. The operational posture is completely different.

    Why From Day One Matters

    Retrofitting observability and security into a live system is significantly more expensive than building it in from the start. Not just in money — in time, risk, and organisational friction.

    When you add a control plane after agents are already in production, you must modify every existing workflow to route through the new layer, backfill logs for actions that already happened, and negotiate with teams accustomed to unfettered agent access. In practice, this work costs roughly three times what it would have cost to build the control plane first — before accounting for the risk exposure during the period agents ran without controls.

    Building it from day one means the control plane is part of the deployment process. Every new agent is onboarded through it. Every execution is logged from the first run. Every cost is tracked from the first token. No migration, no retrofitting, no gap.

    What to Do Next

    If you are running agentic AI in your organisation — or planning to — here is where to start.

    1. Inventory your agents. List every agent, workflow, and automated process that takes action on a business system. Include what systems it accesses, what credentials it uses, and what actions it can perform. You cannot secure what you have not catalogued.

    2. Add structured logging. For every agent execution, log the input, the decision chain, the action taken, the output, and the timestamp. Use a consistent schema. Send these logs to a central, append-only store. If you are using n8n, configure each node to log its input and output. Integrate a tracing tool like Langfuse from the start.

    3. Implement approval gates for high-risk actions. Define which actions require human sign-off: anything client-facing, anything that modifies financial data, anything that changes system configuration. Build the approval gate into the control plane, not into the agent’s prompt.

    4. Set up observability. Deploy an observability layer that tracks execution traces, error rates, token usage, and cost per workflow. Build dashboards. Set alerts for anomalies — sudden cost increases, rising error rates, unusual execution patterns.

    5. Define failure recovery. For every workflow, document what happens on failure. Retry logic, escalation paths, rollback procedures. Test these before you need them.

    The organisations that will extract the most value from agentic AI are not the ones that move fastest. They are the ones that move safely — with the infrastructure to observe, control, and recover from the inevitable failures.

    If you are building agentic systems and need help designing the control plane, observability, and security architecture around them, the AI & Automation Architecture service covers exactly this. For examples of what this looks like in practice, see recent projects.

Powered by