RichardHam.co.uk Blog

Tag: AI

  • Why Dependency Hygiene Becomes a Leadership Issue

    Why Dependency Hygiene Becomes a Leadership Issue

    A lot of teams still treat package upgrades and release housekeeping as purely technical chores.

    That made sense when the application estate was simpler, the change rate was slower, and a missed patch mostly meant a slightly awkward sprint later on. It makes much less sense once your organisation depends on AI services, automation workflows, customer-facing portals, and a growing set of third-party components that can change under your feet.

    This week’s GitHub activity was a useful reminder of that.

    Across several public repos, the work was not centred on a dramatic new feature. It was centred on the quieter jobs that keep live systems usable: upgrading a framework across multiple sites, tightening the way an agent platform distinguishes billing exhaustion from authentication failure, restoring an explicit safety guard with regression coverage, and shipping deployment handover notes alongside a website redesign.

    That mix matters because it points to a broader operating reality: dependency hygiene is no longer just a developer preference. It has become part of leadership discipline.

    The recent GitHub signals were small, but not trivial

    A few examples stood out.

    One public media/website repo recently went through a cluster of framework upgrades across multiple surfaces. On the face of it, those are dependency bumps. In practice, they are evidence of someone choosing not to let the front-end estate drift quietly into a harder future upgrade.

    Another public analytics/cost-tracking repo saw updates to numerical and coverage tooling. Again, this is the sort of work many leadership teams never see. Yet if cost reporting or analytics underpin operational decisions, stale numerical libraries and test tooling are not invisible engineering details. They affect how confidently the team can rely on output.

    In one public agent platform, a recent change separated billing exhaustion from a generic authentication failure, while another restored a missing enabled-guard and added regression tests. Those are strong examples of operational maturity. The first makes failure states easier to understand. The second makes it harder for a disabled service path to behave ambiguously.

    Then there was website delivery work in a public site repo: one change added a deployment handover document, and another shipped the full site build and deploy tooling. That is not just design delivery. It is an acknowledgement that shipping is only half the job if nobody else can support the result safely afterwards.

    Why senior leaders should care about this work

    If you are a founder, managing partner, COO, CIO, or board sponsor, none of this should be dismissed as back-room maintenance.

    Once AI, automation, or client-facing digital journeys are part of the operating model, dependency hygiene becomes a business issue for three reasons.

    1. Drift increases the cost of every later decision

    Technical drift rarely fails all at once. It accumulates quietly.

    A framework stays two major versions behind. A library update gets deferred because it is inconvenient. A brittle edge case stays undocumented because the team who understands it is still around. Nothing looks urgent until a new feature, security fix, or partner integration suddenly depends on clearing months of deferred maintenance.

    That is when the bill arrives.

    For SMEs and founder-led businesses, that usually shows up as delivery drag. For law firms and healthcare organisations, it can also create assurance problems because the stack behind a client-facing process becomes harder to explain. For PE-backed companies, it turns into diligence friction. If the technology estate looks under-maintained, every transformation claim starts to feel less believable.

    2. Poorly classified failures waste leadership attention

    One of the most useful repo changes this week was not a new feature at all. It was the decision in one public agent platform to separate billing exhaustion from a generic auth failure.

    That matters because leaders make bad decisions when the system reports the wrong category of problem.

    If a model provider has hit a spend limit, that is a budget, quota, or supplier-management conversation. If the credentials are wrong, that is a configuration or secrets-management conversation. If both are lumped together as “auth failed”, the team loses time, the escalation path gets muddled, and confidence in the monitoring starts to erode.

    At scale, this is one of the easiest ways for senior people to get dragged into operational noise that should have been designed out earlier.

    3. Handover quality is part of risk control

    I think many organisations still underestimate how much risk sits in the gap between “it works” and “someone else can run it”.

    That is why the deployment handover work in dh-electrical-uk-website is commercially important. When a redesign lands with deploy tooling and supporting handover notes, the delivery is stronger than a visually successful launch on its own. It means the service is more likely to survive staff changes, supplier changes, holiday cover, and the inevitable moment when something needs to be updated under time pressure.

    In practical terms, handover is where a lot of hidden fragility gets exposed:

    • which versions are actually supported
    • which environment assumptions are undocumented
    • which steps still live in one person’s head
    • which recovery actions have never been written down

    If that sounds familiar, the issue is not documentation style. It is operating-model debt.

    What good leadership looks like here

    The answer is not for non-technical leaders to micromanage every package bump.

    The answer is to treat upgrade hygiene, failure clarity, and supportability as visible management concerns. In practice, I would want four things.

    Keep an explicit tolerance for drift

    Not every dependency needs to be latest immediately. But the organisation should know what level of lag is acceptable, where major-version changes are being deferred deliberately, and who owns the call when a deferral becomes risky.

    Insist on failure signals that guide action

    If an automation platform cannot distinguish billing, auth, config, runtime, and policy problems cleanly, the team will spend too much time diagnosing symptoms and not enough time fixing causes.

    Ask for handover evidence before calling a project done

    If a supplier, internal team, or blended delivery setup cannot show you the deploy path, the support notes, and the recovery assumptions, you do not yet have a finished operational asset.

    Connect maintenance discipline to commercial credibility

    Clients, investors, regulators, and acquirers do not usually ask whether numpy or Astro was bumped on Tuesday. They do care whether your digital services are dependable, whether your reporting is trustworthy enough to guide decisions, and whether your systems can be maintained without heroics.

    That is the commercial expression of dependency hygiene.

    A simple question worth asking this quarter

    If your organisation relies on AI, automation, or a modern web estate, ask one blunt question:

    Which live services would become awkward or risky to change if the current operator disappeared for two weeks?

    The answer usually reveals more than a tooling audit alone.

    It shows where drift has been tolerated too long, where failure messages are too vague to manage well, and where handover has been assumed rather than designed. Those are exactly the places where fractional leadership earns its keep, because the problem is rarely just a code problem. It sits across governance, service design, supplier control, and risk appetite.

    If that question exposes uncomfortable gaps, that is useful. It gives you a practical starting point.

    If you want help turning that picture into a calmer operating model, my services cover the overlap between security leadership, IT direction, and AI architecture. Or get in touch if you want a senior review of where maintenance debt, weak handover, or ambiguous failure handling is making change harder than it should be.

  • AI Agent Audit Trails: What to Record Before the Auditor Asks

    Once an AI agent starts taking actions — updating records, sending messages, moving money, calling APIs — the question changes from “is the output good?” to “can you prove what happened?”. Most teams can answer the first question. Very few can answer the second, and that gap tends to surface at the worst possible moment: an ISO 27001 audit, a cyber insurance renewal, or a customer’s security team working through a supplier questionnaire.

    We have written before about why audit trails matter for agentic AI. This piece is about the practical side: what your log actually needs to contain, where it needs to live, and who reviews it.

    Why an agent changes the logging picture

    Traditional application logs record what your software did. An AI agent is a different animal, because three things are running at once: a model making probabilistic decisions, a workflow engine executing steps, and tools acting on live business systems. A log that captures only the final action cannot answer the questions an auditor will ask.

    Specifically, an audit trail for an AI agent run needs to answer:

    – What did the agent see? (the input, including any retrieved context or documents)
    – What did it decide, and with which model and agent version?
    – What did it actually execute, step by step?
    – Who approved it, if a human approval was in the loop?
    – What changed in the underlying systems, before and after?

    What to record for every run

    At minimum, each execution should capture:

    – Identity: which agent ran, which version, which model underneath it. “The AI did it” is not an audit answer; version 2.4 of your triage agent acting through a named model is.
    – Input: what the agent received — the message, document, or trigger, including any context retrieved from your knowledge base. Retrieval-augmented agents are only as auditable as their sources.
    – Tool calls and parameters: every external action the agent took, with the parameters passed. This is usually the line of evidence that reconstructs an incident.
    – Before and after state: what a record looked like before the agent edited it and after. Most disputes reduce to this.
    – Approvals: any human sign-off in the chain, tied to a named person or role, with a timestamp.
    – Outcome and errors: what completed, what failed, and what the agent did in response to the failure.

    Append-only storage matters here. If the log can be edited after the fact, an auditor will treat it as a claim rather than evidence, and they will be right to.

    The UK compliance angle

    Two obligations make this more than good hygiene.

    The UK GDPR accountability principle means you must be able to demonstrate how personal data is processed — and an agent updating customer records is processing, whether or not a human clicked the button. Your records of processing activities should reflect automated agents as processing operations, not sit silently beside them.

    If ISO 27001 is in scope — increasingly a condition of enterprise contracts — logging and monitoring are explicit controls in the standard’s Annex A. Auditors do not accept “we use a platform that probably logs things”. They ask to see the log, the retention policy, and the review routine.

    Insurers are moving the same direction. When a cyber renewal asks how you detect and investigate unauthorised changes, an AI agent audit trail is fast becoming part of the answer.

    Who checks the log, and how often

    A log nobody reads is an expense, not a control. Two routines cover most SME needs:

    – Monthly sample review: pull a handful of agent runs at random, read them end to end, and confirm the actions match the intent. This catches drift — a prompt that has slowly degraded, a tool permission nobody meant to grant.
    – Exception alerting: define the actions that should never happen without a named approver — refunds above a threshold, deletes, anything touching privileged systems — and alert when they occur.

    Someone has to own both routines. Not “the team”, not the agent platform. A named person.

    Red flags worth fixing now

    – Your logs record prompts but not the actions the agent executed.
    – Agent runs are not versioned, so you cannot tell which behaviour produced an old result.
    – The audit trail lives in a system the agent itself can modify.
    – Human approvals are recorded as a generic “approved” with no identity attached.
    – Nobody can name the retention period for agent logs, because nobody chose one.

    None of these require a big programme to fix. Structured logging, append-only storage and a named owner get you most of the way there, and the tooling is ordinary — the discipline is the hard part.

    If your team is rolling out agent workflows and you want an independent view on what an auditor, insurer or enterprise customer will expect to see, get in touch via the contact page.

  • Hermes in the Enterprise: A Security Team’s Threat Model

    Hermes Agent is heading for enterprise networks. On 7 October 2026 the Wall Street Journal reported that Nous Research had raised $90 million at a $1.5 billion valuation to take its open-source agent from individual developers into corporate environments — the article notes more than 22 million downloads since February. This is no longer a tool your most curious engineer runs on a spare VM. It will be bought, piloted and integrated by organisations that answer to auditors, insurers and customers.

    If your team is evaluating Hermes or any agentic AI of this class, what should your security function ask first? Not “is it safe?” — that never gets a useful answer. The right questions: what can this thing do without me, who can talk to it, and how would I know when it did something I would not have approved?

    What Hermes actually does

    Hermes Agent is an autonomous agent from Nous Research, the open-weights lab behind the Hermes model family — not a chatbot bolted onto an API. It uses tool calling to read and write files, run shell commands and code, browse the web, call external APIs and model context protocol servers, and spawn isolated subagents. It runs on terminal backends from your own machine to Docker containers, remote SSH hosts or serverless sandboxes.

    Two features matter most for a threat model. First, the learning loop: Hermes creates and updates its own skills — reusable procedural documents it loads when a task matches — and the official docs state the agent can modify or delete any skill, with human-approved skill writes as an optional gate that is off by default. Second, the messaging gateway: the same agent is reachable from Telegram, Discord, Slack, WhatsApp, Microsoft Teams and more, with built-in scheduling so it runs unattended jobs around the clock. You can message it from your phone while it executes on a server you never log into.

    That combination — persistent autonomy, self-modifying procedure, conversational remote control — is genuinely useful, and a prompt-injection class in production form.

    The threat model

    Prompt injection via web content and files. Hermes reads what you point it at: web pages, documents, repositories, emails. Instructions hidden in that content are indistinguishable from instructions you gave it. This is not hypothetical — in July 2026 researchers published a proof of concept, reported by The Hacker News, showing leading coding agents tricked into executing attacker-supplied binaries via a poisoned README in an open-source repository. Hermes has mitigations — context-file scanning, always-on request forgery protection blocking fetches to private networks, a configurable website blocklist — but the scanning is explicitly heuristic, not semantic. Treat web and file content as untrusted input to a privileged process.
    Malicious or drifting self-created skills. Skills are the agent’s procedural memory, drawn from bundled sets, community hubs, or the agent writing its own. A skill is a markdown document that shapes future behaviour — instructions to ignore approvals, exfiltrate data or quietly widen scope would persist until someone reads the file. Default configuration writes skills freely, and a skill that was correct in March can drift as the environment changes.
    Chat account takeover. Hermes treats whoever can message the gateway as the operator. An attacker who compromises a linked Telegram or Discord account inherits the agent’s access. The gateway has layered authorisation — per-platform user allowlists, pairing codes, deny-by-default when nothing is configured — but consumer chat platforms are not your identity provider.
    Secrets exposure. The agent holds model API keys and can be handed cloud, email and code-hosting credentials. Redaction exists for tool error output, but anything the agent can read — environment files, notes, logs — can end up in a model prompt, a chat message, or a file it writes somewhere public.
    Over-broad permissions. With dozens of built-in tools and shell execution, a default install is a small operating system with your name on it. YOLO mode exists and disables approval prompts entirely; so does flipping approvals off in configuration. Headless surfaces default to denying dangerous commands, but defaults are a floor, not a control set.
    Weak audit trail. Hermes logs locally and keeps session history, but if your security operations team cannot query it, you do not have an audit trail — you have files. An agent acting every few minutes needs central logging before it needs a use case.

    Controls that actually apply

    Most of these exist in Hermes today. The gap in most pilots is that nobody configures them.

    Sandbox execution. Run command execution on the container backend — which drops Linux capabilities, blocks privilege escalation and limits processes — or on a dedicated host behind an SSH backend. Never a domain-joined workstation.
    Gate skill writes and new skills. Turn on the skill write-approval gate so every skill the agent creates or edits is staged for human review. Review staged skills with the seriousness you give code changes; functionally they are.
    Least-privilege credentials. Give the agent scoped keys with hard spend caps, separate from any human admin account. Never one credential that unlocks both infrastructure and production data.
    Disable consumer chat channels, or fence them properly. If the pilot needs messaging, use a dedicated workspace with explicit user allowlists and pairing codes; if not, run CLI-only. Do not bridge an enterprise agent to a personal Telegram account.
    Central logging. Ship gateway and session logs to your existing log platform on day one. Log authorisation denials, approval decisions and skill writes at minimum.
    A kill switch that is really a switch. Hermes does not ship a single named panic button; build one. Stopping the gateway service, revoking platform tokens and disabling API keys are three independent ways to stop it — documented and tested, and placed outside the agent, since Hermes deliberately blocks self-restart from inside its own supervised process.
    Keep it updated, and say no to the easy paths. Run updates for security patches, keep allow-all-user flags off in production, and treat “just disable approvals for the pilot” as the decision it really is.

    Field notes

    I run Hermes myself across my own operations, so these come from real deployments, not lab speculation. Tool names stay; internal infrastructure stays out.

    – Secrets do end up in transcripts. A dedicated scanning and rotation process found hundreds of credential-shaped findings in Hermes session transcripts over a few months — API keys and bearer tokens reaching cloud model contexts through normal tool use. Hermes redacts tool error output, but that is one layer; what the agent reads can still reach a model prompt. Scanning after the fact is no substitute for not feeding it secrets.
    – Skill self-management is double-edged. The agent’s ability to create and edit its own skills is useful — and it also meant every profile loaded the full skill catalogue regardless of relevance, wasting tokens and polluting context with instructions for domains that did not apply. Per-profile isolation was needed to fix it. If the agent writes its own procedures, someone has to review what accumulated.
    – Approval gates create friction — and that friction is the point. My approval gate blocking routine cleanup commands (think `rm -rf` on temp directories after agent work) caused files to pile up. The fix is not to weaken the gate; it is to document an approved alternative path. If your team starts asking to disable approvals to “get things moving”, you have found the real control.
    – Monitoring the agent matters as much as the agent itself. My own budget-and-spend guard cron fired a false critical alert for days because of a logic quirk — reading the wrong figure as budget exhaustion. Automated agents generate automated noise; if nobody owns the monitoring that watches the agent, false alarms and real ones look identical.

    Pre-deployment checklist

    Before Hermes (or anything like it) touches enterprise data:

    1. Written threat model covering injection via every content source the agent reads.
    2. Command execution sandboxed — container or dedicated host, non-root, resource-limited.
    3. Skill write-approval enabled; a named human reviews staged skills.
    4. Credential inventory complete; agent keys scoped, capped and separable.
    5. Chat channels either disabled or on allowlists behind a dedicated workspace.
    6. Central logging live and queried at least once before go-live.
    7. Kill switch documented, owned and tested from outside the agent.
    8. YOLO and approval-off modes blocked by configuration review.
    9. Update and patch cadence assigned to a named owner.
    10. A rollback: what you will do when the first incident happens.

    Most of this is unglamorous. None of it is optional. Agentic AI rewards teams that treat the control plane as the product.

    If your team is evaluating agentic AI and wants a second pair of eyes on the threat model before a pilot starts, my services page covers security and security strategy work for UK businesses — or get in touch and we can talk through where you are.

    Sources

    – WSJ Pro, “Nous Research Scores $90 Million to Bring Open-Source AI Assistant to Enterprises”, 7 October 2026 (funding figure, valuation, enterprise strategy, download count).
    – Hermes Agent official documentation, Nous Research: overview, skills system, security user guide, messaging gateway.
    – The Hacker News, “Top AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It”, 9 July 2026, covering the AI Now Institute “Friendly Fire” proof of concept.

    Flagged, not stated as fact: “kill switch” is operational framing, not a documented Hermes feature; prompt-injection evidence cited is from competing agents; download counts are vendor-reported via WSJ.

  • Before You Launch an AI Assessment, Fix the Operating Model

    Before You Launch an AI Assessment, Fix the Operating Model

    A lot of AI advisory offers now start with an assessment.

    The problem is that many of these offers are still being built like marketing assets rather than client-facing systems.

    If the output influences buying decisions, budget allocation, compliance posture, or board discussion, the operating model behind it matters as much as the prompt or the front end. Recent GitHub work around an AI consultancy assessment build, plus reliability work in adjacent automation repos, makes that obvious.

    The recent signals are not about polish alone

    One assessment build in particular stood out this week.

    The visible activity was not just about shipping a shiny MVP. It included concrete follow-up work such as:

    • provider fallback handling for report generation
    • safer rendering of generated reports and clearer visitor handoff paths
    • lead email notification flows
    • privacy, GDPR, and security controls
    • a protected admin dashboard for internal review

    That list is commercially useful because it shows the build moving away from “can we generate an AI report?” and toward the harder question: “can we run this as a client-facing service?”

    The same instinct showed up elsewhere. In one public agent platform, recent changes added approval requirements around sensitive gateway replacement paths and tightened behaviour when an API server is explicitly disabled. In another internal management context, recent work also focused on surfacing failed or missing configuration steps as real errors rather than false-green output.

    An AI assessment is a service, not a content asset

    This is the point many firms miss.

    An AI assessment may arrive through a landing page, but from the user’s point of view it behaves like a service. It collects inputs. It processes them. It generates output that may shape strategy. It creates follow-up work for your team. It may retain commercially sensitive information. It may trigger email workflows or lead handling.

    That means buyers, especially in law firms, healthcare organisations, PE-backed businesses, and regulated SMEs, will judge it on more than whether the wording feels intelligent.

    They will care about questions such as:

    • What happens if the model fails halfway through a report?
    • Where does the submitted information go?
    • Who can see the results internally?
    • Will someone follow up while the lead is still warm?

    Those are operating-model questions. If they are answered late, the launch becomes fragile. If they are answered early, the assessment becomes a serious commercial asset.

    The four controls I would design before launch

    When I look at the recent issue set, I see four controls that should exist before any AI assessment is treated as production-grade.

    1. Fallbacks for report generation

    Provider fallback handling is one of the first giveaways that the team is thinking properly.

    If your report workflow depends on a single provider, a temporary outage or degraded model response can turn a promising user journey into a dead end. A fallback model path does not need to be elaborate on day one, but it does need to exist. You should know:

    • which provider is primary
    • which fallback path is acceptable
    • how quality is checked before the output is shown
    • what the user sees if both paths fail

    2. Safe rendering and an explicit handoff path

    Safe rendering and an explicit handoff path may sound like front-end housekeeping, but they are more important than that.

    AI-generated output often carries awkward structure, inconsistent formatting, and the occasional sentence that reads far more confidently than the evidence supports. Treat output rendering as a control surface: sanitize it, structure it, keep the language disciplined, then give the reader a clear next step.

    A practical CTA is part of the safety model here, not just the conversion model. If the output is intended to open a commercial conversation rather than substitute for expert judgement, the interface should say so and point naturally to the services page or the contact page.

    3. Privacy, GDPR, and role-based access

    For UK buyers, especially in legal and healthcare environments, privacy, GDPR, and role-based access are where a build starts becoming credible.

    An assessment tool often collects exactly the sort of operational detail that organisations do not want sprayed across logs, inboxes, and loosely protected admin views. Decide early:

    • what data is stored
    • what is redacted or minimised
    • how long submissions are retained
    • which internal roles can access raw answers
    • what the lawful basis and privacy notice look like

    A protected admin dashboard belongs in the same conversation. Internal convenience is not a good enough reason for weak access control.

    4. Truthful monitoring and approvals around the edges

    The adjacent repo activity matters here because it reinforces a broader discipline.

    If a nightly check can go false-green, or a gateway action can happen without the right approval, your delivery stack is already telling you something about risk appetite. Public agent-platform fixes and internal management work both point to the same lesson: the system around the assessment needs honest signals and controlled change paths.

    For a buyer-facing AI assessment, keep one rule in mind: do not automate yourself into ambiguity.

    If emails fail, surface it. If a fallback is used, log it. If an admin action changes routing or content, require the right level of review. If an integration is disabled, behave safely and obviously rather than trying to muddle through.

    That is how you keep confidence high without pretending the system is infallible.

    Where this lands commercially

    This is not only a product design issue. It affects how the market reads your firm.

    A well-run assessment signals seniority. It tells a prospect that you understand not just AI tooling, but governance, service design, delivery risk, and follow-through. A weakly controlled assessment suggests the front-end story is outrunning the operating reality behind it.

    For founder-led firms, that usually shows up as missed leads, messy handovers, and inconsistent output. For more regulated sectors, it can create trust friction before a proposal is even on the table.

    A sensible pre-launch checklist

    Before putting an AI assessment in front of serious buyers, I would want five things in place:

    • a tested fallback path for report generation
    • sanitised, structured output with a clear advisory disclaimer where needed
    • a defined CTA path into the services page or the contact page
    • privacy, retention, and access decisions written down
    • alerts and admin workflows that fail visibly rather than silently

    That will not make the launch flashy. It will make it usable.

    And in this category, usable beats flashy every time.

    If you are building an AI assessment, advisory funnel, or client-facing automation journey and want the surrounding controls designed properly, my services cover that mix of security leadership, IT operating model, and AI architecture. If you already have something live, get in touch and I can help you pressure-test it before it becomes a trust problem.

  • GitHub Weekly — Inventory Reconciliation, Safer Automation, and Pilot Delivery

    GitHub Weekly — Inventory Reconciliation, Safer Automation, and Pilot Delivery

    When I reviewed this week’s GitHub activity, one pattern kept showing up across very different repos: the work was not really about adding more moving parts. It was about making the existing parts easier to trust.

    That showed up in infrastructure work, in the agent and governance layer, in product scaffolding, and even in website and brand updates. The common thread was operational credibility. Not “can this be built?” but “can this be run, understood, and improved without guesswork?”

    I think that distinction matters more than most teams admit. Plenty of systems can be made to work for a day. Far fewer are built to survive handovers, edge cases, and the quiet failure modes that only show up once the initial excitement wears off.

    What happened

    1. Inventory and infrastructure work moved from assumptions to reconciliation

    The clearest technical thread this week sat in the infrastructure estate.

    A cluster of commits and pull requests focused on inventory reconciliation, NetBox alignment, deployment timers, backup coverage, and preserving state correctly during synchronisation. The details matter here because they point to a mature kind of problem.

    This was not “set up monitoring” or “add a backup.” It was more specific than that:

    • preserving existing custom fields during sync instead of bluntly overwriting them
    • wiring host variables so the live inventory reflects the real estate more faithfully
    • adding a reconciliation timer so drift is checked regularly rather than relying on memory
    • tightening the documentation around port management and incident handling
    • adding backup paths around Git hosting and PostgreSQL exports so recovery is not left to best intentions

    That is serious operational work.

    A lot of teams stop once the first integration works. But once you have lived with an estate for a while, the harder problem is not connectivity — it is fidelity. Does your inventory still describe reality? Does your synchronisation preserve the parts of the system that humans added for a reason? Do your backups exist as a runnable path, not just a sentence in a plan?

    I also noticed a Terraform validation gate land in the same broader operating context. Again, that is a small change on paper, but it says something useful about the direction of travel: the systems are being nudged toward earlier feedback and fewer silent mistakes.

    That is usually a good sign. Mature platforms do not just automate more; they fail sooner and more visibly.

    2. Safer automation is becoming a design principle rather than a patch

    A second pattern was the continued tightening of automation boundaries.

    In the management and agent repos, the work touched cron behaviour, gateway restart safety, regression coverage, secret-scanning governance, prompt and model hygiene, and more explicit handling of runtime assumptions. There was also activity around daily “Decision Desk” issues and weekly cost rollups, which reinforces the sense that operational review is becoming a routine surface rather than an occasional scramble.

    What stood out to me was not any one fix in isolation. It was the posture behind them.

    The posture seems to be:

    • make hidden dependencies visible
    • stop false-green checks from looking healthy when they are not
    • separate human-only actions from safe automation paths
    • keep governance records close to the implementation work
    • add tests around the boundaries that matter most

    That is the right instinct for any agentic or semi-autonomous system.

    There is a temptation in AI and automation work to obsess over capability and underinvest in control. But the systems that earn trust over time are usually the opposite. They may look less flashy at first, but they are the ones people keep using because the failure modes are legible.

    I often find that the best progress in these environments comes from boring-sounding work: a better guard, a clearer runbook, a fix that prevents a check from hiding a broken path, or a cleaner boundary between what the machine can do alone and what still needs a person.

    That kind of work compounds.

    3. New product and pilot work is being framed with real operational shape from the start

    There was also a healthy amount of activity around new product and pilot work.

    One stream built out an AI consultancy-oriented assessment flow with issue scaffolding for the API, persistence, report generation, visitor-safe rendering, lead notifications, privacy controls, and admin protection. Another stream pushed a pilot roadmap forward with legal review notes, request packs, costing artefacts, rehearsal runbooks, and status-gate updates.

    This is the sort of work I like to see early.

    It suggests the projects are not being treated as presentation-layer exercises. They are being built with the surrounding machinery in mind:

    • how the workflow stores and protects data
    • how output gets generated with fallbacks
    • what supporting documents are needed before a pilot becomes real
    • what commercial and legal edges need handling before delivery starts
    • what a rehearsal path looks like before someone is relying on it

    That is a much stronger way to start an AI project than simply chasing a polished demo.

    The same practical mindset also showed up in the website work. The brand alignment and navigation adjustments in the main site repo, along with the redesign and deployment handover work in a separate website project, both point to an important truth: delivery is never just code. It is also handover, consistency, content structure, and operational clarity once the thing is live.

    Why this week matters

    What connects all of this is a shift from implementation to operability.

    I do not mean that the build phase is over. Clearly it is not. There is still plenty being created. But the work is increasingly shaped by questions like:

    • Can this system survive drift?
    • Can somebody else understand the current state quickly?
    • Can an automated path be trusted not to hide the real failure?
    • Can a pilot be delivered without inventing the commercial and governance pieces at the last minute?
    • Can the visible front end stay aligned with the operational reality behind it?

    Those questions are where systems start becoming durable.

    They are also where a lot of technical teams quietly win or lose time. If you skip them, you pay later through rework, brittle deployments, unclear ownership, and incident response that starts with archaeology. If you handle them early, the platform becomes easier to change because it is easier to reason about.

    Key takeaways

    A few practical lessons came through clearly this week.

    • Reconciliation beats assumption. A live inventory is only useful if it keeps matching reality. Sync jobs and timers are not admin overhead; they are how trust is maintained.
    • State preservation matters as much as state collection. It is not enough to ingest live data if the process wipes the context humans added deliberately.
    • Guard rails are product work. In agent and automation systems, restart safety, explicit boundaries, and truthful checks are not secondary concerns.
    • Pilots need legal and operational scaffolding early. Rehearsal runbooks, request packs, privacy controls, and delivery notes are signs of seriousness, not bureaucracy.
    • Good delivery includes the handover path. Website and product work both improve when documentation, navigation, and deployment steps are treated as first-class.

    If I had to reduce the whole week to one line, it would be this: the strongest systems in the batch were the ones being made easier to trust, not merely easier to demo.

    Closing thought

    This week’s most interesting GitHub activity was not one dramatic launch. It was the repeated decision to replace ambiguity with structure.

    That happened in infrastructure reconciliation, in safer automation boundaries, in early-stage product scaffolding, and in content and website delivery work. Each change on its own might look incremental. Together, they point in a useful direction: systems that are easier to operate, easier to hand over, and harder to misunderstand.

    That is the sort of progress I pay attention to.

    If you are building AI workflows, internal tooling, or customer-facing systems and want them to be robust as well as impressive, that is exactly the kind of work I help with through services and more focused advisory conversations via contact.

  • 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.

Powered by CookieAdmin