RichardHam.co.uk Blog

Tag: security

  • What Real Delivery Discipline Looks Like

    What Real Delivery Discipline Looks Like

    A lot of teams say they care about security and reliability. Fewer teams build delivery habits that prove it.

    That difference matters more than most strategy decks admit. Hardening work is easy to describe in principle. Everyone agrees that authentication should be stronger, fallbacks should be safer, and monitoring should be more truthful. The real question is whether those concerns are allowed to shape the delivery path itself.

    If they are not, the system ends up with good intentions and brittle behaviour.

    Hardening is not a final polish step

    One of the most persistent delivery mistakes is treating hardening as something that happens after the “real” build is done.

    In practice, the opposite is true. Security-sensitive choices usually need to be made while the implementation is still taking shape:

    • what credentials are allowed to reach which component
    • what action is taken when verification fails
    • whether a degraded path is acceptable or whether the job should stop
    • what evidence an operator needs before calling something healthy
    • how much trust the system gives to generated output by default

    Those are not edge details. They shape the behaviour of the whole stack.

    If the hardening conversation starts only once the workflow is already live, the team ends up retrofitting controls around assumptions that were never designed for scrutiny.

    Monitoring has to be able to disagree with the diagram

    A good architecture diagram can still hide a weak operating model.

    I see this most often in monitoring. Teams build checks that confirm whether the process is running, but not whether the real task is succeeding in a meaningful way. That produces the worst kind of comfort: the dashboard looks clean while the system is quietly failing at the thing that matters.

    Useful monitoring needs to be willing to contradict appearances.

    For example, I would rather know that:

    • the workflow completed but returned structurally bad output
    • the service stayed up but fell onto the wrong provider path
    • the API responded but the downstream data plane was empty
    • the fallback recovered execution but created a lower-trust result

    That kind of signal is less glamorous than a green uptime chart, but it is far more useful when somebody has to operate the platform at speed.

    Delivery discipline is mostly about reducing hidden surprises

    The phrase “delivery discipline” can sound heavier than it needs to. I do not mean process theatre. I mean building a path to change that does not rely on luck.

    In practical terms, the teams that do this well tend to share a few habits:

    They make verification part of the job

    A change is not finished because the command returned zero. It is finished when the operator can show that the intended behaviour is visible from the outside.

    They do not improvise every rollback

    If a deployment path matters, the recovery path should already exist before the incident.

    They keep release logic legible

    The more a release process depends on one person remembering unwritten exceptions, the less mature it is.

    They distinguish activity from progress

    A lot of work can happen in a sprint without improving the trustworthiness of the system. Good delivery discipline asks whether the change made the operating model clearer, safer, or easier to verify.

    Why this matters in AI and automation work

    Automation makes weak delivery habits more expensive because the system can now repeat them at scale.

    If a manual operator makes one bad judgement call, the damage is limited. If the workflow itself contains vague trust boundaries, shallow health checks, or unclear fallback rules, the same weakness can repeat every minute.

    That is why I treat discipline as a feature.

    Not in the moral sense. In the architectural sense.

    A disciplined delivery path gives the team:

    • safer defaults
    • clearer escalation points
    • more credible monitoring
    • easier handover between operators
    • fewer silent regressions

    That is not bureaucracy. It is what makes the rest of the system believable.

    What I would check first

    If I am assessing whether a delivery process is genuinely disciplined, I usually start with a small checklist:

    • are the trust boundaries obvious?
    • does the monitoring test real behaviour or just process existence?
    • can somebody explain the fallback path without guessing?
    • is there a documented way to verify the live result after a change?
    • would another operator know what “healthy” means from the artefacts alone?

    If the answer to those questions is mostly “not yet”, then the team probably does not have a tooling problem. It has a delivery-discipline problem.

    The good news is that this is fixable. Most of the gains come from clearer defaults, sharper verification, and a willingness to treat operational trust as part of the design instead of a layer you add afterward.

    That work is rarely flashy. It just means the system behaves like something serious.

    If your stack needs stronger delivery discipline around hardening, observability, or AI workflows, the AI & Automation Architecture and Security Strategy work is built around exactly those problems. Or get in touch if you want a practical review of where the delivery path is still carrying too much guesswork.

  • GitHub Weekly — Security Hardening, Monitoring, and Delivery Discipline

    GitHub Weekly — Security Hardening, Monitoring, and Delivery Discipline

    Introduction

    Some weeks are about visible progress: a new feature, a fresh integration, a launch announcement. Other weeks are about the work that keeps those things safe to run. This was one of those weeks.

    Across the repos I reviewed, the pattern was consistent. Security controls were tightened, monitoring got corrected rather than just expanded, operational runbooks were written down instead of left in people’s heads, and delivery work kept moving in small, deliberate steps. That is not glamorous work, but it is the kind of work that stops a platform from becoming fragile.

    The theme that emerged was simple: maintenance is not separate from delivery. It is part of delivery.

    What happened

    Security work moved from incident response to operating discipline

    In hermes-mgmt, the work was clearly shaped by hard lessons. Prompt injection concerns were captured in the changelog and backlog, webhook authentication was hardened, Qdrant backups were automated, and CVE verification was folded into the wider hardening effort.

    That combination matters. A lot of teams treat security as a single event — a scan, a policy review, a one-off fix. In practice, it is a chain of habits. You need authentication on the edges, backups in the middle, and verification at the end. If any one of those is missing, the system may still look healthy right up until the day it is not.

    What I liked most about this pattern was that the repo was not just reacting to a risk. It was converting the risk into repeatable operations: operator scripts, backlog triage, and the documentation needed to make the next decision easier than the last one.

    Monitoring got corrected, not just decorated

    In hamnet, the week was dominated by practical observability fixes. Grafana datasource timing was corrected, dashboard defaults were adjusted to now-6h, pushgateway metrics were refined, and time series queries were updated so they would render reliably instead of misleadingly.

    That sounds minor until you have lived through a dashboard that lies to you.

    Monitoring failures are often subtle. The data is present, the panels load, and the colours look reassuring — but the time interval is wrong, the step size is off, or the query is hiding the very behaviour you wanted to see. In that state, dashboards become theatre. They exist, but they do not help.

    There was also a useful governance signal in the tracking of HTTP-only services that still need HTTPS evaluation. That is exactly the sort of operational backlog item that gets forgotten unless someone records it explicitly. Good monitoring is not only about more charts. It is about acknowledging what is still unfinished and making that visible.

    AI automation was tightened with guardrails and auditability

    ms365-agentic-ai was another strong example of maturity through constraint. Prompt-injection and AI-security guards were hardened, a hub-and-spoke team operating model was merged in, a plan-only remote command action was introduced, and cost-first routing became part of the model strategy.

    This is the right direction for agentic systems. The mistake many teams make is to optimise for autonomy too early. They want the agent to do more before they have decided how to constrain it, audit it, or roll it back. That is how you end up with a clever demo and an unsafe production system.

    The useful pattern here is the opposite: make autonomy conditional. Limit the command surface. Make some actions plan-only. Keep an audit trail. Route routine work to cheaper models where appropriate. When a system can explain what it intended to do before it does it, you are much closer to something governable.

    Delivery work stayed concrete and decomposed

    ricambio-ai-roadmap looked like a good example of steady execution rather than big-bang progress. Provider configuration UI work landed, pagination and infrastructure fixes followed, LaunchDaemon plists and boot startup scripts were added, and a run-sheet for an onsite email MVP visit was written down.

    There was also a practical focus on PII redaction and provider bake-off work, which tells me the team is thinking about both usability and safety. That combination is important. A delivery track is strongest when it can handle real-world constraints without losing momentum.

    The interesting part here is not any one commit. It is the sequence. Research, configuration, bootstrapping, runbooks, redaction, delivery. That is what healthy delivery looks like when it is being treated as a system rather than a one-off project.

    Governance became a daily rhythm

    The control-tower repo reinforced the same message from a different angle. Daily “Decision Desk” issues kept appearing, which tells me governance is not being treated as a monthly review or a backlog afterthought. It is being made into a rhythm.

    That matters because the absence of rhythm is what creates drift. If you only review decisions occasionally, then the rationale behind them disappears into chat threads and memory. If you capture them daily, you create a trail that can be checked, challenged, and reused.

    Why this matters

    The common thread across all of this work is that automation only becomes trustworthy when it is surrounded by discipline.

    Security controls matter because agents, webhooks, and operational tools all expand the number of ways a system can be influenced.

    Monitoring matters because a dashboard that is technically live but operationally wrong can be worse than no dashboard at all.

    Runbooks matter because the first time something breaks, people rarely have time to invent the procedure from scratch.

    And delivery discipline matters because every project eventually reaches a point where execution is more about coordination, sequencing, and proof than raw feature count.

    I think that is why this week felt coherent even though the repos were diverse. The activity was not random. It was converging on a single operating idea: if you want automation to scale, you have to make the surrounding system easier to trust.

    That means:

    • tightening the edge of the system with authentication and verification
    • making dashboards accurate enough to act on
    • writing down the operational steps before they are needed in anger
    • splitting risky work into smaller, reviewable pieces
    • keeping audit trails and decision logs close to the work itself

    Those are not just engineering habits. They are management habits.

    Key takeaways

    • Security hardening is strongest when it becomes a repeatable operating pattern, not a one-off response.
    • Monitoring is only useful if the time windows, query intervals, and defaults actually match the system you are trying to observe.
    • Agentic systems need guardrails, auditability, and plan-only steps before they need more autonomy.
    • Delivery improves when work is decomposed into concrete, sequenced steps with runbooks and release notes alongside the code.
    • Governance becomes useful when it is captured as a daily rhythm rather than a periodic ceremony.

    This week did not hinge on a single dramatic release. It showed something more important: the system is getting better at protecting itself while it moves.

    That is the work that keeps the next launch calm.

    If you are building automation, AI systems, or operational dashboards and want help turning the hidden work into a reliable operating model, the AI & Automation Architecture service covers exactly this. Or get in touch if you want a practical conversation about making the system easier to trust.

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

  • Hardening Without Drama

    Hardening Without Drama

    This was one of those weeks where the work that mattered most was the work nobody would notice if it went right. That usually means it is important.

    What changed

    • The security posture got tighter at the edges. A system that handles real work needs controls that survive when the environment changes.

    • Observability was also pushed a little closer to the truth. Good metrics do not flatter the operator; they tell you what is actually happening.

    • Several changes pointed to the same idea: if a process can fail, it should have a clear fallback and a clear owner.

    Closing thought

    The useful version of hardening is calm. No theatre, no chest-beating, just fewer weak spots and better recovery when something does break.

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

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

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

    g

    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.

  • CrewAI Launch: Building Secure Agent Crews

    s

    When multi-agent tooling matured in late 2024, it solved one problem and exposed another. Coordination got easier. Risk did too.

    A system that can research, draft, test, and propose changes is useful. A system that can do all of that without a clear approval path is a liability.

    The basic shape

    Agent orchestration
-> local inference
-> secret handling
-> human approval

    That setup sounds obvious now. It did not feel obvious at the time.

    The first production uses were straightforward: security reviews, repetitive checks, and content drafting. The output was good enough to save time, but only when the guardrails stayed in place.

    Lessons that stuck

    • Give each agent the minimum access it needs.
    • Log outputs before anything changes state.
    • Test for prompt injection and bad assumptions early.

    Those three habits did more for reliability than any naming convention or framework choice.

    What changed

    The real shift was mental. I stopped thinking about agents as clever helpers and started treating them like junior team members. Useful, yes. Trusted by default, no.

    That distinction matters. A junior teammate can ask questions and escalate. An unchecked automation chain just keeps moving.

    The safest systems are boring in the right ways. They make decisions visible. They make mistakes recoverable. They let a human step in before the wrong thing becomes the permanent thing.

Powered by