RichardHam.co.uk Blog

Tag: AI

  • Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    The conversation around AI in business has shifted. For the past two years, most organisations have experimented with generative AI as a productivity tool — drafting documents, summarising meetings, answering questions. The model receives input, produces output, and a human reviews the result.

    That is no longer the whole picture.

    Across the organisations I work with, AI is moving from answering questions to taking actions. Agents execute n8n workflows that move data between systems. They trigger Hermes agents that read, write, and decide. They call APIs, update records, send messages, and make operational decisions — sometimes with human approval, sometimes without.

    This is agentic AI: systems that do not just respond, but act. It creates a governance problem that clever prompts alone cannot solve.

    The Governance Gap

    When a human makes a decision in a business process, there is usually a trace. An email sent, a form submitted, a system log entry, a manager’s sign-off. When something goes wrong, you can reconstruct the sequence of events. You can ask: what were they asked to do, what did they do, and why?

    When an AI agent executes an action, that trace often does not exist. The agent receives a prompt, processes it through one or more model calls, and performs an action. If the action is wrong — if it updates the wrong record, sends a message to the wrong person, or executes a workflow it should not have — the organisation is left with a result and no explanation.

    This is not a theoretical risk. In my own infrastructure, I have built agentic workflows that interact with live systems. The difference between a safe deployment and an unsafe one is not the quality of the prompt. It is whether the system logs enough information to reconstruct what happened after the fact.

    What Happens Without Audit Trails

    Without audit trails, three things break down.

    You cannot reconstruct events. If an agent produces an incorrect output or takes an unintended action, you need to know what input it received, which model or tool it called, what intermediate decisions it made, and what action it executed. Without this, debugging is guesswork. You are trying to diagnose a problem without access to the patient’s notes.

    You cannot establish accountability. When an automated system causes harm — a data breach, a financial error, a compliance failure — someone needs to be able to explain what happened. Under UK GDPR, the accountability principle requires organisations to demonstrate compliance, not just claim it. If your AI agent processes personal data and you cannot show what it did with that data, you are not compliant. It does not matter how good the system is in theory.

    You cannot improve the system. Agentic AI systems iterate. You adjust prompts, change tool configurations, add guardrails. Without structured logs of what each execution actually did, you are optimising in the dark.

    What a Practical Audit Trail Looks Like

    An audit trail for an agentic AI system does not need to be complex. It needs to be consistent and complete. At minimum, each agent execution should capture:

    • Input received. What was the agent asked to do? This includes the user’s request, any system context, and the prompt that was constructed.
    • Decision chain. What steps did the agent take? Which tools did it call? What intermediate outputs did it produce? For multi-step agents, this is the sequence of reasoning that led to the final action.
    • Action taken. What did the agent actually do? Which API was called, which record was updated, which message was sent.
    • Output produced. What was the final result returned to the user or passed to the next step in the workflow.
    • Timestamp and identity. When did this happen, and which agent or workflow executed it?

    This is not excessive. It is the same information you would expect from any business system that takes actions on data. The fact that the system is powered by a language model does not change the requirement — it increases it, because the system’s behaviour is less deterministic and harder to predict.

    The Regulatory Dimension

    For UK organisations, this is not optional. UK GDPR Article 5(2) establishes the accountability principle: you must be able to demonstrate that you comply with data protection principles. If an AI agent processes personal data — and most business agents do — you need to show what data it accessed, what it did with that data, and on what basis.

    Article 30 requires records of processing activities. An agent that processes client records, employee data, or customer information is conducting processing activity. If you cannot produce a log of that activity, you do not have the records the regulation requires.

    For financial services firms, the FCA’s operational resilience framework adds another layer. Important business services must withstand disruption and recover. If your AI agents are part of an important business service — processing transactions, managing client communications, monitoring risk — you need to understand how they behave, what they depend on, and what happens when they fail. Audit trails are the evidence base for your resilience assessment.

    How to Implement Audit Trails in Agent Workflows

    The good news is that the tooling exists. You do not need to build this from scratch.

    Structured logging at every node. In n8n workflows, each node can be configured to log its input and output. For agentic workflows, you should log at minimum the trigger, each decision point, and the final action. Use a consistent schema — timestamp, node name, input summary, output summary, and execution status — so that logs are searchable and comparable.

    Observability platforms. Tools like Langfuse are designed for exactly this purpose. They capture the full execution trace of an agent: prompt, model response, tool calls, and final output. When connected to your workflow engine, they give you a queryable record of every agent execution without building custom logging infrastructure.

    Immutable storage. Audit logs must be tamper-evident. If the log can be modified after the fact, it is not an audit trail — it is a diary. Store logs in append-only storage with access controls that prevent modification. This can be as simple as writing to a write-once bucket or using a logging service that enforces retention policies.

    Structured output from agents. Design your agents to return structured output, not just free text. A JSON response that includes the action taken, the target system, and the rationale is far more useful for auditing than a paragraph of prose. This also makes it easier to validate agent behaviour programmatically — you can check that the action taken is within the set of permitted actions before it executes.

    Regular review. Audit trails are only useful if someone looks at them. Build a review cadence — weekly for high-risk agents, monthly for lower-risk ones — where you sample executions and check for anomalies.

    The Bottom Line

    The organisations that will get the most value from agentic AI are not the ones with the most sophisticated prompts. They are the ones that can trust their agents to act safely, verify what those agents did, and improve them over time.

    Audit trails are the foundation of that trust. They are how you move from hoping your agents behave to knowing they do. They are how you satisfy regulators, reassure boards, and sleep at night.

    If you are deploying agentic AI in your organisation — or planning to — audit infrastructure is not a phase-two consideration. It is a prerequisite.

    If you are building agentic AI systems and need help establishing the governance, architecture, and audit infrastructure to support them, the AI & Automation Architecture service covers exactly this. For a broader conversation about where your organisation stands, get in touch.

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

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

  • Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    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.

  • Weekly GitHub Activity — 22–29 June 2026

    Introduction

    Another busy week in the repositories. Between infrastructure automation, platform hardening, commercial product development, and a small mountain of documentation, the commit logs tell the story of a systemthat’s rapidly moving from “hand-crafted and held together with SSH sessions” toward something far more repeatable and governed. Let’s walk through what landed.

    What Happened

    hermes-mgmt: Hardening, Governance, and AI Spend Controls

    The hermes-mgmt repository saw 10 commits and 20 pull requests this week, almost all of them orbiting two themes: Tier 2 operational hardening and AI spend governance.

    On the hardening side, a suite of operator runbooks and governance records landed — documenting the execution of Tier 2 hardening scripts, session decisions from backlog triage, and a full operator TODO instruction document. PR #694 tackled memory infrastructure head-on, covering a Qdrant deployment, gateway shutdown procedures, and Telegram 429 rate-limit handling. PR #695 addressed bug remediation across Spotify integration, n8n authentication, vision/video backend issues, and a 429 retry storm that was causing more harm than good.

    The AI spend work is particularly interesting. PR #696 introduced budget policies, cost telemetry, context-optimisation strategies, and prompt-caching controls — essentially an AI spend optimisation control plane. As LLM-powered workloads grow, having a formal mechanism to track, cap, and optimise spend is no longer nice-to-have; it’s operational hygiene. The design docs for child components that accompanied this work sketch out a system where every agent invocation carries a cost context, and budget alarms fire before the invoice does.

    Security compliance also got attention. PR #691 documented progress against SecureScore controls SEC-002, SEC-006, RES-002, and MAT-001 — a reminder that even in a solo-operator environment, treating compliance as code keeps the audit trail honest.

    A quieter but important fix: PR #640 made the Mem0→Letta memory backfill idempotent, preventing duplicate records on re-runs. Small change, big impact on data integrity.

    hamnet: The Control Plane Takes Shape

    hamnet was the most active repository this week — 10 commits, 18 pull requests, and 40 open issues. The headline is the emergence of a single-pane control-plane dashboard (PR #183), backed by a growing collection of infrastructure collectors.

    The control-plane work is being built incrementally and deliberately:

    • PR #177 established the identity model, a static inventory MVP, and the first batch of workload collectors.
    • PR #179 added a second batch — AgentRadar, Ollama status, repository state, and NetBox integration.
    • PR #176 fixed Grafana drift authentication and a tvheadend timeout issue that was causing monitoring gaps.

    On the infrastructure-as-code front, PR #178 delivered a comprehensive IaC roadmap with schemas, runbooks, and a system-classification model. PR #194 proposed enforcing unattended-upgrades policies on external cloud hosts through Ansible — a defensive measure that ensures security patches land even when nobody’s watching.

    Several fixes made day-to-day operations smoother: a script to tag missing VMs with ansible:managed in NetBox (commit 33d2fd9), a UTF-8 locale fix for ansible-inventory (commit 198d9b8), and adding Gitea to the Docker container detection logic (commit a950c67) — a gap that meant the monitoring stack was blind to a self-hosted service.

    A Docker image drift management runbook (commit 81fa372) and operator runbooks for 11 infrastructure issues (commit 8f09076) round out the picture. hamnet is building the operational backbone: not just running services, but knowing what’s running, whether it should be, and what to do when it isn’t.

    The 40 open issues deserve a mention — they’re a candid inventory of what needs attention, from an Oracle scanner that’s out of sync and a PVE exporter reporting zero metrics to Loki missing log-shipping and stale NetBox entries. Filing them is half the battle.

    ms365-agentic-ai: Collectors, Cost Controls, and Production Readiness

    The ms365-agentic-ai repository is accelerating. Five commits this week laid significant groundwork:

    • A deployable Azure Functions host with a run-history sink and live-path tests (commit 5465364).
    • Live read-only fetch wiring for all collectors (commit 416c537).
    • A cost-management component combining an estimator with an Azure cost collector (commit 86ab202).
    • Production-readiness runbook with dry-run and preflight tooling (commit 5da09c4).
    • A simple start guide, docs index, and FAQ/troubleshooting section (commit 212729a).

    The 10 open issues (#6–#15) are essentially the product roadmap: approval-gated remediation models, audit logging, Teams health digests, Azure resource health and Defender XDR collectors, Graph permissions matrices, and licensing/cost matrices. What’s notable is the breadth — this isn’t just a tool, it’s an operational platform being designed with governance from the start.

    richardham-co-uk-ConsultancyOS: Commercial Foundations

    ConsultancyOS — the commercial operating-system template — got its infrastructure in order this week. PR #12 added CI, licensing, a contributing guide, and a docs handbook. A SessionStart hook for web sessions (commit 1a54d22) shows the product thinking extending into the user experience.

    The 9 open issues map out the productisation journey: operational dashboards, a GitHub delivery-repo template, LLM integration, n8n workflow scaffolding, accountant review processes, company identity, and integrations with Dolibarr CRM and Invoice Ninja. This is a project that’s explicitly moving from “personal tooling” toward “repeatable commercial offering.”

    on-maintenance-ai-roadmap: Client-Facing Delivery

    The on-maintenance-ai-roadmap repository focused on communication and deployment model this week. A client-facing project plan (PR #23), an Architecture Decision Record for production hosting in client-owned Azure (PR #21), and a deploy-from-GitHub infrastructure model (PR #24) all point to a delivery pattern where the client retains ownership and control of their environment while the project provides the automation and intelligence layer.

    ai-cloud-credits-grant: Cloud Funding Applications

    Six commits across the ai-cloud-credits-grant repository added usage plans for NVIDIA Inception, Cloudflare, Oracle OCI, AWS, and Google Cloud. These are structured applications for cloud-provider credit programmes — the kind of unglamorous but essential work that unlocks compute capacity for projects that need it. The 6 open issues track the remaining work: a master company profile, applications to the major providers, and an evidence pack.

    Key Takeaways

    1. The control plane is real. hamnet’s dashboard, collectors, and identity model aren’t prototypes — they’re an incremental build toward a system that provides visibility and governance across the entire infrastructure. When you can see everything from one pane, you can fix things before they break.

    2. AI spend is now a first-class concern. The hermes-mgmt AI spend control plane — with budget policies, cost telemetry, and prompt caching — reflects a mature approach to LLM operations. The era of “just call the API and hope the bill is reasonable” is over, at least in this stack.

    3. Documentation as a delivery artifact. Across every repository this week, documentation wasn’t an afterthought — it was a first-class deliverable. Operator runbooks, governance records, ADRs, client-facing plans, and onboarding guides shipped alongside the code. This is the behaviour that separates sustainable projects from weekend hacks.

    4. Compliance isn’t optional, even for small teams. The SecureScore work in hermes-mgmt and the approval-gated remediation model in ms365-agentic-ai show that compliance and auditability are being designed in, not bolted on. That’s cheaper and more effective at any scale.

    5. Open issues are a feature, not a bug. hamnet’s 40 open issues and ms365-agentic-ai’s 10 open issues aren’t backlogs — they’re transparent roadmaps. Filing what needs doing, and making it visible, is how solo operators avoid the “I’ll remember that later” trap.

    This post is part of a weekly series summarising GitHub activity across the project portfolio. Previous entries are available in the blog archive.

  • Weekly GitHub Activity — 22–29 June 2026

    Introduction

    Another busy week in the repositories. Between infrastructure automation, platform hardening, commercial product development, and a small mountain of documentation, the commit logs tell the story of a systemthat’s rapidly moving from “hand-crafted and held together with SSH sessions” toward something far more repeatable and governed. Let’s walk through what landed.

    What Happened

    hermes-mgmt: Hardening, Governance, and AI Spend Controls

    The hermes-mgmt repository saw 10 commits and 20 pull requests this week, almost all of them orbiting two themes: Tier 2 operational hardening and AI spend governance.

    On the hardening side, a suite of operator runbooks and governance records landed — documenting the execution of Tier 2 hardening scripts, session decisions from backlog triage, and a full operator TODO instruction document. PR #694 tackled memory infrastructure head-on, covering a Qdrant deployment, gateway shutdown procedures, and Telegram 429 rate-limit handling. PR #695 addressed bug remediation across Spotify integration, n8n authentication, vision/video backend issues, and a 429 retry storm that was causing more harm than good.

    The AI spend work is particularly interesting. PR #696 introduced budget policies, cost telemetry, context-optimisation strategies, and prompt-caching controls — essentially an AI spend optimisation control plane. As LLM-powered workloads grow, having a formal mechanism to track, cap, and optimise spend is no longer nice-to-have; it’s operational hygiene. The design docs for child components that accompanied this work sketch out a system where every agent invocation carries a cost context, and budget alarms fire before the invoice does.

    Security compliance also got attention. PR #691 documented progress against SecureScore controls SEC-002, SEC-006, RES-002, and MAT-001 — a reminder that even in a solo-operator environment, treating compliance as code keeps the audit trail honest.

    A quieter but important fix: PR #640 made the Mem0→Letta memory backfill idempotent, preventing duplicate records on re-runs. Small change, big impact on data integrity.

    hamnet: The Control Plane Takes Shape

    hamnet was the most active repository this week — 10 commits, 18 pull requests, and 40 open issues. The headline is the emergence of a single-pane control-plane dashboard (PR #183), backed by a growing collection of infrastructure collectors.

    The control-plane work is being built incrementally and deliberately:

    • PR #177 established the identity model, a static inventory MVP, and the first batch of workload collectors.
    • PR #179 added a second batch — AgentRadar, Ollama status, repository state, and NetBox integration.
    • PR #176 fixed Grafana drift authentication and a tvheadend timeout issue that was causing monitoring gaps.

    On the infrastructure-as-code front, PR #178 delivered a comprehensive IaC roadmap with schemas, runbooks, and a system-classification model. PR #194 proposed enforcing unattended-upgrades policies on external cloud hosts through Ansible — a defensive measure that ensures security patches land even when nobody’s watching.

    Several fixes made day-to-day operations smoother: a script to tag missing VMs with ansible:managed in NetBox (commit 33d2fd9), a UTF-8 locale fix for ansible-inventory (commit 198d9b8), and adding Gitea to the Docker container detection logic (commit a950c67) — a gap that meant the monitoring stack was blind to a self-hosted service.

    A Docker image drift management runbook (commit 81fa372) and operator runbooks for 11 infrastructure issues (commit 8f09076) round out the picture. hamnet is building the operational backbone: not just running services, but knowing what’s running, whether it should be, and what to do when it isn’t.

    The 40 open issues deserve a mention — they’re a candid inventory of what needs attention, from an Oracle scanner that’s out of sync and a PVE exporter reporting zero metrics to Loki missing log-shipping and stale NetBox entries. Filing them is half the battle.

    ms365-agentic-ai: Collectors, Cost Controls, and Production Readiness

    The ms365-agentic-ai repository is accelerating. Five commits this week laid significant groundwork:

    • A deployable Azure Functions host with a run-history sink and live-path tests (commit 5465364).
    • Live read-only fetch wiring for all collectors (commit 416c537).
    • A cost-management component combining an estimator with an Azure cost collector (commit 86ab202).
    • Production-readiness runbook with dry-run and preflight tooling (commit 5da09c4).
    • A simple start guide, docs index, and FAQ/troubleshooting section (commit 212729a).

    The 10 open issues (#6–#15) are essentially the product roadmap: approval-gated remediation models, audit logging, Teams health digests, Azure resource health and Defender XDR collectors, Graph permissions matrices, and licensing/cost matrices. What’s notable is the breadth — this isn’t just a tool, it’s an operational platform being designed with governance from the start.

    richardham-co-uk-ConsultancyOS: Commercial Foundations

    ConsultancyOS — the commercial operating-system template — got its infrastructure in order this week. PR #12 added CI, licensing, a contributing guide, and a docs handbook. A SessionStart hook for web sessions (commit 1a54d22) shows the product thinking extending into the user experience.

    The 9 open issues map out the productisation journey: operational dashboards, a GitHub delivery-repo template, LLM integration, n8n workflow scaffolding, accountant review processes, company identity, and integrations with Dolibarr CRM and Invoice Ninja. This is a project that’s explicitly moving from “personal tooling” toward “repeatable commercial offering.”

    on-maintenance-ai-roadmap: Client-Facing Delivery

    The on-maintenance-ai-roadmap repository focused on communication and deployment model this week. A client-facing project plan (PR #23), an Architecture Decision Record for production hosting in client-owned Azure (PR #21), and a deploy-from-GitHub infrastructure model (PR #24) all point to a delivery pattern where the client retains ownership and control of their environment while the project provides the automation and intelligence layer.

    ai-cloud-credits-grant: Cloud Funding Applications

    Six commits across the ai-cloud-credits-grant repository added usage plans for NVIDIA Inception, Cloudflare, Oracle OCI, AWS, and Google Cloud. These are structured applications for cloud-provider credit programmes — the kind of unglamorous but essential work that unlocks compute capacity for projects that need it. The 6 open issues track the remaining work: a master company profile, applications to the major providers, and an evidence pack.

    Key Takeaways

    1. The control plane is real. hamnet’s dashboard, collectors, and identity model aren’t prototypes — they’re an incremental build toward a system that provides visibility and governance across the entire infrastructure. When you can see everything from one pane, you can fix things before they break.

    2. AI spend is now a first-class concern. The hermes-mgmt AI spend control plane — with budget policies, cost telemetry, and prompt caching — reflects a mature approach to LLM operations. The era of “just call the API and hope the bill is reasonable” is over, at least in this stack.

    3. Documentation as a delivery artifact. Across every repository this week, documentation wasn’t an afterthought — it was a first-class deliverable. Operator runbooks, governance records, ADRs, client-facing plans, and onboarding guides shipped alongside the code. This is the behaviour that separates sustainable projects from weekend hacks.

    4. Compliance isn’t optional, even for small teams. The SecureScore work in hermes-mgmt and the approval-gated remediation model in ms365-agentic-ai show that compliance and auditability are being designed in, not bolted on. That’s cheaper and more effective at any scale.

    5. Open issues are a feature, not a bug. hamnet’s 40 open issues and ms365-agentic-ai’s 10 open issues aren’t backlogs — they’re transparent roadmaps. Filing what needs doing, and making it visible, is how solo operators avoid the “I’ll remember that later” trap.

    This post is part of a weekly series summarising GitHub activity across the project portfolio. Previous entries are available in the blog archive.

  • The Secrets Management Mistakes I See in AI Infrastructure

    The Secrets Management Mistakes I See in AI Infrastructure

    I have reviewed dozens of AI infrastructure stacks over the past year. The pattern is depressingly consistent: a team spins up Langfuse for LLM observability, adds n8n for workflow automation, plugs in Hermes or another AI agent — and within a month, there are database passwords committed to git and API keys baked directly into Docker Compose files.

    It is not that these teams do not care about security. It is that the tooling is easy to deploy and terrifyingly easy to deploy wrong. The secrets management layer is an afterthought, and by the time anyone notices, the rot is already baked into the repository history — often with several stale copies scattered across forks, CI logs, and deployment scripts.

    The tools are not the problem. The defaults are survivable if you change them immediately and manage them properly. The problem is that almost nobody does.

    Why this matters now

    AI infrastructure is different from a typical web app in one important respect: it holds the keys to your models, your data pipelines, and increasingly, your customer data. When a secrets leak happens in an AI stack, it is not just a credential rotation exercise. It can mean exposing vector stores full of proprietary documents, handing over API keys with uncapped billing, or losing control of an agent that has been given broad access to your internal systems.

    UK SMEs are adopting these tools faster than their security practices can keep up. Boards are asking for AI capability. Technical founders want to move fast. The result is that Langfuse and n8n instances go live with the same enthusiasm and the same rigour as a weekend side project.

    The NCSC has been clear that the shared responsibility model applies here. The platform provides the controls. You have to configure them. And right now, most teams deploying AI infrastructure are not.

    A war story from the field

    I recently reviewed a deployment where the Langfuse Docker Compose file had been committed to a version-controlled repository with production database credentials hardcoded directly into it. Not in an environment variable reference — the actual username and password, sitting in plaintext in a file that had been committed, reviewed, merged, and deployed.

    That was not the only issue. The same deployment had a Claude configuration that did not properly handle credential rotation after operator restarts. Every time the container restarted — patching, scaling, node migration — the service would silently fall back to insecure defaults. Nobody noticed for weeks because the service appeared to be running. It was running. It was just doing so with credentials that had long since been rotated and should no longer have been valid.

    I also found an n8n instance where the encryption key had not been persisted. The team had recreated their n8n container as part of a routine update, and the platform generated a new encryption key on startup. Every credential stored in n8n’s database became undecryptable. Every workflow that depended on stored API keys, database connections, or OAuth tokens broke simultaneously.

    The error message is admirably specific: “A different encryptionKey was used to encrypt the data.” But by the time you see it, all of your workflows are failing in production — and unless you have the original encryption key backed up somewhere outside the container, those credentials are gone.

    These are not edge cases. They are the most common findings in every AI infrastructure review I have done in the last twelve months.

    The five mistakes I see most often

    1. Hardcoded secrets in Docker Compose and environment files

    This is the big one. Teams copy a docker-compose.yml from a project README, fill in their passwords in plaintext, and commit it. Sometimes they remember to add .env to .gitignore but leave the Compose file itself exposed. Sometimes they move the secrets to an environment file but commit that too, because the .gitignore was only added after the first commit.

    2. Using default credentials past the first five minutes of setup

    Default credentials exist so you can get started quickly. They should exist in production for approximately zero seconds after the health check passes. I regularly find admin/admin or changeme on instances that have been running for months, sometimes years. If a tool ships with a default password, changing it should be the very first action in your runbook — not something you plan to do later.

    3. Losing the encryption key when containers are recreated

    This one catches people out constantly with n8n, but it applies to any platform that encrypts stored credentials. When you recreate a container without persisting the encryption keys, a new one is generated and the old data is orphaned. The platform cannot protect you from this. It is a configuration decision. You need to persist encryption keys outside the container lifecycle — in your secrets manager, in your CI/CD pipeline configuration, in a mounted volume that survives container recreation.

    4. Treating the AI stack as lower risk than the rest of the infrastructure

    There is a pernicious perception that the “AI tools” are supplementary, experimental, not worth the same rigour as the production database or the payment gateway. This is backwards. Your AI stack touches your most sensitive data — the documents you embed, the conversations you log, the internal APIs your agents call. It has the broadest external API surface in your architecture. It deserves more scrutiny, not less.

    5. Relying on git history alone to “remove” secrets

    Committing a secret, then removing it in a follow-up commit, does not remove it from git history. It just adds another commit on top. The secret is still there, reachable via git log -p, via GitHub’s commit history, via any clone or fork. Once a secret has been committed, the only safe response is rotation — treat it as compromised and issue new credentials.

    What to do next

    You do not need an enterprise secrets vault to get the basics right. You need a checklist and the discipline to follow it.

    1. Audit your repositories now. Search for common patterns: PASSWORD=, SECRET=, API_KEY=, base64-encoded blobs in environment files. Use tools like gitleaks or trufflehog to scan both current state and history. If anything turns up, rotate the credentials immediately — do not just remove them from the latest commit.

    2. Externalise every secret. In Docker Compose, reference ${VAR} values and use a .env file that is .gitignored at the repository root level. If you are on a managed platform, use its native secrets manager. No exceptions, no “just for now”, no “it is only a development environment.”

    3. Persist your n8n encryption key. Set the N8N_ENCRYPTION_KEY environment variable explicitly — do not let n8n auto-generate it. Store it in your secrets manager and make it part of your container orchestration configuration, not the container itself. Back it up. Test that you can restore it.

    4. Rotate after every environment change. When a container is recreated, when a team member leaves, when you are not even sure something was exposed — rotate. Treat the cost of rotation as negligible compared to the cost of a breach. Automate it wherever you can.

    5. Apply the same standard to AI tools as everything else. Your Langfuse instance, your n8n deployment, your AI agent platform — these hold credentials and data that would interest an attacker. Give them the same security treatment you would give a production database. No concessions for “it is internal” or “it is just a prototype.”

    Where Richard can help

    If you are deploying AI infrastructure and want an honest assessment of how your secrets are managed — before an incident forces the conversation — I offer infrastructure security reviews and fractional CISO engagements tailored to UK SMEs running containers, workflows, and AI tooling.

    The mistakes above are among the most common findings in the engagements I do. They are also almost always fixable in a day.

    Get in touch or review the available services to arrange a review.

  • GitHub Weekly — SecureScore Goes Live, Agentic Ops Mature, and the Atlas Foundation Takes Shape

    Introduction

    Seventy-four repos, one week, and a surprising amount of shipped work. This week’s activity spans three themes: production security tooling crossing from plan into live operation, agentic infrastructure maturing with better observability and failover, and a new initiative — the Atlas Foundation — taking shape around public-good AI proposals. Here’s what happened, what shipped, and what it signals.

    What Happened

    SecureScore: From Dry-Run to Live

    The Hermes SecureScore project crossed a meaningful threshold this week. After install dry-runs and collector CLI fixes over the previous days, the project recorded its live activation on June 19. The Docker collector for SecureScore evidence shipped, a config collector bug for string provider entries was fixed, and the evidence pipeline moved from testing to production. On the dashboard side, the main Hermes Agent repo merged PR #1 adding a SecureScore view, confirming this isn’t a standalone experiment but an integrated part of operations.

    Why it matters: security评分 that runs locally, on your own infra, without sending data externally — that’s a pattern more teams will need as AI agent deployments multiply and audit requirements tighten.

    Hermes Mgmt: Dashboard v0.17 and the Work Behind It

    The management dashboard saw a methodical series of doc-and-script updates. Highlights:

    • v0.17.0 migration guide published, including a process restart requirement — a small detail that saves a lot of “why isn’t this working?” confusion.
    • Langfuse cost analytics landed as a cross-provider spend report with a weekly digest cron. Teams running multi-model setups can now track spend across providers without spreadsheet gymnastics.
    • Agent Tool Audit Report 2026-06-24 opened as a PR, systematically cataloguing what the agent toolkit actually contains and where the gaps are.
    • Telegram flood protection (Layers 3+4+5) merged, covering restart hygiene, notification deduplication, and rate-limit handling.
    • Security vulnerability remediation — 16 CVEs patched across nltk and starlette dependencies.

    The pattern here isn’t glamorous features; it’s the unglamorous maintainability work that keeps agent infrastructure from rotting.

    Agentic Coordination: Failover, Cost Awareness, and Escalation

    Three PRs from the Hermes Mgmt repo tell a story about agentic ops moving past the demo phase:

    1. Local-primary triage and tiered escalation (PR #624) — an EPIC outlining how a local model (Hermes3:8b) handles first-tier requests and escalates to stronger models when responses are weak or empty. This is the failover tier the project has been building toward.
    2. Credit-awareness fix plan for OpenRouter — because nothing kills an agent workflow faster than hitting a model credit limit mid-task without warning.
    3. Agent Radar got its initial commit with a roadmap of MVP tasks: detector rules for common agent frameworks, repo status badges, and schema examples. The idea is to build a tool that scans repos and identifies agent frameworks automatically.

    Infrastructure: Hardening and Monitoring

    On the infrastructure side:

    • Hamnet shipped SSH hardening for the VPS with a dynamic-IP allowlist failsafe — the kind of defensive depth that matters when IPs change and locks you out. Vhost routing was also hardened after an incident where a domain served the wrong site.
    • Ollama dashboard and metrics pipeline (Hamnet PR #134) — because if you’re running models locally, you need to know the server is alive without checking manually.
    • A WordPress blog import runbook was added, documenting the pipeline that keeps the blog publishing workflow reproducible.

    Atlas Foundation: Public-Good Agent Proposals

    The project-atlas-foundation repo saw significant activity: candidate proposals scored, shaping docs created, and a safety checklist added. The current proposal slate includes:

    • An open-source issue triage assistant
    • A digital-access assistant for elderly users
    • A small charity automation kit
    • A public-good agent template library

    A Claude Code handover document was added for the team, covering setup, sync, and triage workflows — suggesting the project is moving from concept to collaborative execution.

    HamMediaLabs: Governance Deepening

    HamMediaLabs shipped a wave of internal governance: onboarding guides, a development guide, risk register, branch hygiene policy, and a PR review dashboard with dependency health reporting. For a small team, this is the scaffolding that prevents chaos as contributors scale up.

    Key Takeaways

    1. Production security is becoming operational, not aspirational. SecureScore’s live activation is a signal that local-first security scoring is viable for small teams without enterprise tooling budgets.

    2. The agent ops story is shifting from “can we build it?” to “can we keep it running?” Flood protection, cost dashboards, failover tiers, and tool audits — this is the maintenance phase of the agentic infrastructure lifecycle.

    3. Multi-model cost visibility is now a first-class concern. Langfuse cost analytics with cross-provider reporting, OpenRouter credit-awareness, and tiered escalation — these all reflect the reality that running multiple AI models costs real money and needs real monitoring.

    4. Governance-as-code is emerging in smaller projects. HamMediaLabs and Atlas Foundation both shipped policy documents as code: branch hygiene, risk registers, safety checklists. This is where the industry is heading — compliance documentation that lives in the repo, not in a SharePoint graveyard.

    Code Snippet: Dynamic SSH Allowlist

    From the Hamnet infrastructure work, a pattern worth showing — dynamically resolving an ISP’s current IP for an SSH allowlist, with a failsafe that doesn’t lock you out:

    #!/usr/bin/env bash
# update-ssh-allowlist.sh — refresh dynamic IP in allowlist
set -euo pipefail

CURRENT_IP=$(curl -s --max-time 5 https://ifconfig.me)
KNOWN_FALLBACK="203.0.113.0/24"  # static backup range

if [[ "$CURRENT_IP" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
    iptables -D INPUT -p tcp --dport 22 -j DROP 2>/dev/null || true
    iptables -A INPUT -s "$CURRENT_IP/32" -p tcp --dport 22 -j ACCEPT
    echo "Updated: $CURRENT_IP/32"
else
    iptables -A INPUT -s "$KNOWN_FALLBACK" -p tcp --dport 22 -j ACCEPT
    echo "Fallback applied: $KNOWN_FALLBACK"
fi

    The key insight: always have a fallback. Dynamic DNS is reliable until the day your ISP changes your IP at 2 AM and you can’t SSH in to fix it.

    Data source: commits, issues, and PRs from 49 repositories over the past 7 days. Collected via the GitHub CLI on 2026-06-25.

  • GitHub Weekly — SecureScore Goes Live, Agentic Ops Mature, and the Atlas Foundation Takes Shape

    Introduction

    Seventy-four repos, one week, and a surprising amount of shipped work. This week’s activity spans three themes: production security tooling crossing from plan into live operation, agentic infrastructure maturing with better observability and failover, and a new initiative — the Atlas Foundation — taking shape around public-good AI proposals. Here’s what happened, what shipped, and what it signals.

    What Happened

    SecureScore: From Dry-Run to Live

    The Hermes SecureScore project crossed a meaningful threshold this week. After install dry-runs and collector CLI fixes over the previous days, the project recorded its live activation on June 19. The Docker collector for SecureScore evidence shipped, a config collector bug for string provider entries was fixed, and the evidence pipeline moved from testing to production. On the dashboard side, the main Hermes Agent repo merged PR #1 adding a SecureScore view, confirming this isn’t a standalone experiment but an integrated part of operations.

    Why it matters: security评分 that runs locally, on your own infra, without sending data externally — that’s a pattern more teams will need as AI agent deployments multiply and audit requirements tighten.

    Hermes Mgmt: Dashboard v0.17 and the Work Behind It

    The management dashboard saw a methodical series of doc-and-script updates. Highlights:

    • v0.17.0 migration guide published, including a process restart requirement — a small detail that saves a lot of “why isn’t this working?” confusion.
    • Langfuse cost analytics landed as a cross-provider spend report with a weekly digest cron. Teams running multi-model setups can now track spend across providers without spreadsheet gymnastics.
    • Agent Tool Audit Report 2026-06-24 opened as a PR, systematically cataloguing what the agent toolkit actually contains and where the gaps are.
    • Telegram flood protection (Layers 3+4+5) merged, covering restart hygiene, notification deduplication, and rate-limit handling.
    • Security vulnerability remediation — 16 CVEs patched across nltk and starlette dependencies.

    The pattern here isn’t glamorous features; it’s the unglamorous maintainability work that keeps agent infrastructure from rotting.

    Agentic Coordination: Failover, Cost Awareness, and Escalation

    Three PRs from the Hermes Mgmt repo tell a story about agentic ops moving past the demo phase:

    1. Local-primary triage and tiered escalation (PR #624) — an EPIC outlining how a local model (Hermes3:8b) handles first-tier requests and escalates to stronger models when responses are weak or empty. This is the failover tier the project has been building toward.
    2. Credit-awareness fix plan for OpenRouter — because nothing kills an agent workflow faster than hitting a model credit limit mid-task without warning.
    3. Agent Radar got its initial commit with a roadmap of MVP tasks: detector rules for common agent frameworks, repo status badges, and schema examples. The idea is to build a tool that scans repos and identifies agent frameworks automatically.

    Infrastructure: Hardening and Monitoring

    On the infrastructure side:

    • Hamnet shipped SSH hardening for the VPS with a dynamic-IP allowlist failsafe — the kind of defensive depth that matters when IPs change and locks you out. Vhost routing was also hardened after an incident where a domain served the wrong site.
    • Ollama dashboard and metrics pipeline (Hamnet PR #134) — because if you’re running models locally, you need to know the server is alive without checking manually.
    • A WordPress blog import runbook was added, documenting the pipeline that keeps the blog publishing workflow reproducible.

    Atlas Foundation: Public-Good Agent Proposals

    The project-atlas-foundation repo saw significant activity: candidate proposals scored, shaping docs created, and a safety checklist added. The current proposal slate includes:

    • An open-source issue triage assistant
    • A digital-access assistant for elderly users
    • A small charity automation kit
    • A public-good agent template library

    A Claude Code handover document was added for the team, covering setup, sync, and triage workflows — suggesting the project is moving from concept to collaborative execution.

    HamMediaLabs: Governance Deepening

    HamMediaLabs shipped a wave of internal governance: onboarding guides, a development guide, risk register, branch hygiene policy, and a PR review dashboard with dependency health reporting. For a small team, this is the scaffolding that prevents chaos as contributors scale up.

    Key Takeaways

    1. Production security is becoming operational, not aspirational. SecureScore’s live activation is a signal that local-first security scoring is viable for small teams without enterprise tooling budgets.

    2. The agent ops story is shifting from “can we build it?” to “can we keep it running?” Flood protection, cost dashboards, failover tiers, and tool audits — this is the maintenance phase of the agentic infrastructure lifecycle.

    3. Multi-model cost visibility is now a first-class concern. Langfuse cost analytics with cross-provider reporting, OpenRouter credit-awareness, and tiered escalation — these all reflect the reality that running multiple AI models costs real money and needs real monitoring.

    4. Governance-as-code is emerging in smaller projects. HamMediaLabs and Atlas Foundation both shipped policy documents as code: branch hygiene, risk registers, safety checklists. This is where the industry is heading — compliance documentation that lives in the repo, not in a SharePoint graveyard.

    Code Snippet: Dynamic SSH Allowlist

    From the Hamnet infrastructure work, a pattern worth showing — dynamically resolving an ISP’s current IP for an SSH allowlist, with a failsafe that doesn’t lock you out:

    #!/usr/bin/env bash
# update-ssh-allowlist.sh — refresh dynamic IP in allowlist
set -euo pipefail

CURRENT_IP=$(curl -s --max-time 5 https://ifconfig.me)
KNOWN_FALLBACK="203.0.113.0/24"  # static backup range

if [[ "$CURRENT_IP" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
    iptables -D INPUT -p tcp --dport 22 -j DROP 2>/dev/null || true
    iptables -A INPUT -s "$CURRENT_IP/32" -p tcp --dport 22 -j ACCEPT
    echo "Updated: $CURRENT_IP/32"
else
    iptables -A INPUT -s "$KNOWN_FALLBACK" -p tcp --dport 22 -j ACCEPT
    echo "Fallback applied: $KNOWN_FALLBACK"
fi

    The key insight: always have a fallback. Dynamic DNS is reliable until the day your ISP changes your IP at 2 AM and you can’t SSH in to fix it.

    Data source: commits, issues, and PRs from 49 repositories over the past 7 days. Collected via the GitHub CLI on 2026-06-25.

  • GitHub Weekly: Memory Architecture, Health Probes, and the Quiet Work of Production Hardening

    GitHub Weekly: Memory Architecture, Health Probes, and the Quiet Work of Production Hardening

    The week of June 15-22 was not defined by a single dramatic event. Instead, it was the kind of week that separates platforms that merely work from platforms that hold up under sustained pressure. Across 50 repositories, over 100 events — commits, pull requests, issues — pushed forward several long-running threads: memory architecture, health monitoring, security governance, and the unglamorous but essential work of keeping production infrastructure honest.

    What Happened

    hermes-mgmt — Hardening the Core

    The hermes-mgmt repository remained the busiest node in the network, with 20-plus commits, 20 PRs, and 13 issues. The dominant theme was memory system reliability. A significant fix (PR covering issues #573, #574, #575) hardened dual_memory.py across three dimensions: Ollama-first Mem0 configuration, deterministic Letta archival behaviour, and Qdrant vector dimension alignment. These are the kinds of fixes that don’t make headlines but prevent the subtle data corruption that erodes trust in AI systems over time.

    A related fix (issue #411) corrected a memory drift check that was comparing the wrong Letta data — core-memory passages instead of ARCHIVAL passages. This is a telling detail: as memory architectures grow more layered (core, archival, vector), the surface area for misaligned reads increases. Catching this before it caused silent data degradation matters.

    Health probes got a major upgrade with PR #568, which introduced functional health checks for services that report as “green” but are actually broken — Letta, n8n, Langfuse, Qdrant, Gateway, and Ollama. This is a pattern anyone running distributed systems will recognise: the dashboard shows all green, but something is quietly failing. Functional probes go beyond “is the process running?” to “does the service actually respond correctly?” — a distinction that matters enormously in production.

    Secrets management continued to mature. PR #552 delivered a comprehensive secrets management architecture built around Bitwarden and HashiCorp Vault, while PR #527 removed committed default secrets from the Langfuse compose configuration. These are the foundational security practices that need to be in place before scale makes them painful to retrofit.

    On the cron and scheduling side, the system now runs 38 cron jobs with 36 healthy — a 95% health rate that reflects the cumulative effect of weeks of hardening work. PR #504 corrected cron exit-code semantics so that findings and alerts are no longer misinterpreted as failures, which was causing unnecessary noise in the monitoring pipeline.

    Several open issues point to the next layer of work: Telegram flood-control protection (#583), gateway ungraceful shutdown (#582), Ollama-agent sequential dispatch performance (#580), and a Langfuse Cost Report cron that’s been disabled due to stale API keys (#576). None of these are emergencies, but they represent the known gaps that get addressed in order of priority.

    hamnet — Infrastructure Truth

    The hamnet repository, which manages infrastructure automation, saw 9 commits and 10 PRs with a focus on hosting hardening and monitoring.

    SSH hardening was codified for the VPS fleet (PR #131), including a dynamic-IP allowlist failsafe — a practical safeguard for environments where IP addresses shift. Vhost routing was hardened after www.theitrevolution.co.uk was found serving the wrong site, a class of misconfiguration that can be difficult to spot without deliberate verification.

    On the monitoring side, an Alertmanager webhook receiver was added with X-Webhook-Token authentication (PR #87), and a new Mac AI Server dashboard was built for the Ollama era (PR #134). The dashboard work reflects a broader shift: as the AI infrastructure stack evolves (Ollama replacing previous model servers), the monitoring layer needs to evolve in parallel or it becomes a liability rather than an asset.

    An open issue (#95) flags an SSL certificate SAN mismatch for www.richardham.co.uk — the kind of thing that works until it doesn’t, usually at the worst possible moment.

    hermes-agent — Gateway Stability

    The hermes-agent repository received 10 commits focused on gateway reliability. The command-line matcher was hardened, Windows restart no longer causes a silent outage, and the gateway now refreshes its cached agent max_iterations from the current config rather than stale values. A fix for dict choice unwrapping in the clarify function rounds out a set of small but meaningful stability improvements.

    These are the fixes that users never notice — because they prevent the failures that would have been noticed. Silent outages and stale config caches are particularly insidious because they can persist for extended periods before manifesting as user-visible problems.

    hermes-securescore — Evidence Collection

    The SecureScore project advanced with 9 commits and 2 PRs, adding both a Docker collector and a Hermes config collector for security evidence. A high-risk action approval playbook was also added, formalising the governance process for sensitive operations. The project recorded its live activation this week — a milestone that moves it from development into operational use.

    hermes-voice-satellite — Laying Groundwork

    The voice satellite project saw 9 commits establishing the MVP build plan, an operations runbook, a Hermes voice satellite API contract, and a Termux bootstrap script for Android (S24). A native Android app placeholder was also added. This is early-stage infrastructure work — the kind of foundation that needs to exist before feature development can accelerate.

    project-atlas-foundation — Launch Readiness

    Project Atlas received 10 commits focused on governance and launch preparation: a PR template, MIT licence, security policy, CODEOWNERS, a safety checklist, research workflow, promotion process, CI configuration, and hardened lifecycle guides. Scoring of proposals #3-#7 was completed alongside shaping docs and a launch checklist update. This is the organisational scaffolding that turns a codebase into a project other people can contribute to.

    AgentRadar — New Arrival

    AgentRadar received its initial commit this week. Details are sparse, but a new repository appearing in the portfolio is always worth noting — it represents a new thread that will either find its place or be retired honestly.

    richardham-web-and-Brand — Content Pipeline

    The web-and-brand repository saw 10 commits and 5 PRs, primarily focused on blog publishing and content pipeline maintenance. Four new blog posts in the agentic AI series were added with proper date spacing, and a build fix declared window.__calComLoaded to resolve a strict type-check failure. A WordPress publishing blocker was documented (VPS SSH key issue), which is the kind of honest infrastructure transparency that keeps content pipelines reliable.

    Key Takeaways

    Memory architecture is the new frontier. The volume of work on dual-memory hardening, Letta archival alignment, and Qdrant dimension matching signals that the memory subsystem has become a first-class concern. As AI agents handle longer and more complex tasks, the reliability of their memory layer directly determines the reliability of everything built on top of it. The drift-check fix — comparing the right data — is a small change with outsized implications.

    Functional health probes close a critical gap. The distinction between “process is running” and “service is working” is one of the most common blind spots in monitoring. Adding functional probes for six core services moves the observability stack from surface-level to meaningful. This is the kind of investment that pays for itself the first time it catches a green-but-broken service before a user does.

    Security governance is becoming systematic, not reactive. Between the secrets management architecture, the SecureScore evidence collectors, the high-risk action approval playbook, and the removal of committed defaults, the pattern is clear: security is being built into the development process rather than bolted on after incidents. This is the maturation path every platform needs to follow.

    Infrastructure truth matters. The hamnet work — SSH hardening, vhost routing fixes, SSL certificate monitoring, dashboard reconciliation — is the unglamorous foundation that everything else depends on. When www.theitrevolution.co.uk serves the wrong site, no amount of AI sophistication compensates. Keeping the infrastructure layer honest is a continuous discipline, not a one-time project.

    The content pipeline is converging with the platform. The parallel work on blog publishing, brand positioning, and the agentic AI content series is not separate from the technical work — it is how the technical work becomes visible and valuable. A hardened platform with strong governance needs an equally strong narrative around it.

    Looking Ahead

    The open issues across the portfolio paint a clear picture of next week’s priorities: resolve the Telegram flood-control design, address the gateway ungraceful shutdown path, fix the Langfuse Cost Report cron’s stale API keys, and close the SSL certificate SAN mismatch. On the infrastructure side, the Mac AI Server Ollama dashboard and metrics pipeline need to land, and the remaining open PRs in the web-and-brand repository need to progress through review.

    The velocity of the last week is notable not for its drama but for its consistency. Every repository moved forward. No single event dominated. That is what a healthy development portfolio looks like in practice — not a single sprint, but sustained, disciplined progress across every layer of the stack.

Powered by