RichardHam.co.uk Blog

Tag: UK

  • The M365 Audit You Can Run Before Calling a Consultant

    The M365 Audit You Can Run Before Calling a Consultant

    Last month I published a post about the M365 security baseline most SMEs skip — the default tenant configuration that leaves businesses exposed because no one with security expertise has reviewed it since the initial migration.

    That post explained what to check. This one gives you the tool to check it.

    I built an open-source M365 Audit Toolkit and put it on GitHub. It is a set of read-only PowerShell modules that connect to your tenant using your credentials, interrogate the configuration, and produce a structured report of what is misconfigured, missing, or ranging beyond what you would reasonably accept. It does not change anything. It does not write data. It reads, evaluates, and reports.

    And it is designed so that you can run it yourself — before you pick up the phone to a consultant.

    Why a Self-Service Audit

    Most UK SMEs operate in a state of confident uncertainty about their M365 tenant. The IT provider set it up. It works. Email flows. SharePoint files sync. Teams calls connect. Everything appears fine.

    But “fine” is not a security posture. It is an absence of visible failure.

    The problem is that the gaps in an M365 tenant are invisible until they are not. A compromised account exposes every SharePoint site the user can reach. A forgotten guest account with access to a shared folder persists indefinitely. A mailbox that has never been audited leaves no trail when something goes wrong. These gaps do not generate alerts. They do not appear in the admin console with a red warning icon. They sit quietly until a breach unmasks them, a subject access request forces you to find every piece of personal data in the tenant, or a client’s due diligence questionnaire asks questions you cannot answer.

    I built the toolkit because the cost of a structured audit should not be a barrier to knowing where you stand. You should not need to engage a consultant just to find out whether your conditional access policies are configured, your admin roles are clean, or your retention policies align with your data retention schedule.

    Run the audit first. Understand your gaps. Then decide whether you need help closing them.

    What the Toolkit Covers

    The M365 Audit Toolkit is modular. You can run the full audit or pick the modules relevant to your situation currently and build from there. At present it covers five areas.

    Security Baseline Assessment. Checks MFA enforcement across all users, verifies that legacy authentication protocols is blocked, reviews conditional access policy configuration, mailbox auditing status, and DLP label deployment. This maps directly to the seven controls most SMEs skip.

    Admin Role Hygiene. Identifies every global administrator in the tenant, flags accounts that should not hold that role, checks for service principal permissions that grant equivalent access, and reports on role-based access control adoption for other administrative functions. If your tenant has four, six, or eight global admins, this module will tell you exactly who they are and what they can do.

    Guest Access Audit. Enumerates every external guest account in the tenant, what they can access, when they were last active, and whether access reviews are configured. This is the module that finds the former contractor who still has access to your shared folders three years after their engagement ended — which is more common than you would think.

    SharePoint and OneDrive Governance. Reviews site-level sharing settings, detects externally shared content, checks for orphaned sites, and reports on storage allocation and versioning configuration. If you have ever wondered how much of your organisation’s data is sitting in personal OneDrive accounts that the business does not back up and cannot access, this module provides the answer.

    AI Readiness Evaluation. Assesses your tenant’s readiness to adopt Copilot and other AI services safely — reviewing sensitivity label coverage, data loss prevention configuration, and access controls that would govern what an AI service can surface to users. This is increasingly relevant as Microsoft bundles Copilot into enterprise and business tiers.

    How to Run It

    The toolkit uses interactive MFA authentication, meaning it connects as you and inherits your permissions. It does not require app registrations, client secrets, or service accounts. If you have global reader access to the tenant, you can run the audit.

    The general workflow:

    1. Clone the repository from GitHub and review the modules.
    2. Connect to your tenant using interactive browser-based MFA authentication.
    3. Select the modules relevant to your assessment — security baseline, guest access, governance, AI readiness, or all of them.
    4. Review the output as a structured summary showing what passed, what failed, and what needs attention.

    The entire process can be completed in under an hour for a typical SME tenant. The output is a point-in-time snapshot — it does not persist data, and it does not leave artefacts in your tenant beyond the sign-in logs generated by your own authentication.

    When to Call a Consultant

    Running the audit yourself is the right first step. But there are situations where the findings will tell you that it is time to bring in expertise.

    • The report is long and you do not know where to start. If every module returns significant findings, the remediation effort is material and benefits from prioritisation and sequencing — which is exactly what a structured engagement provides.
    • You lack the permissions or authority to make changes. If the audit reveals that conditional access policies need to be reconfigured but your IT provider controls the tenant, the value of the report is in telling you exactly what to ask for and why.
    • You are preparing for client due diligence, a cyber insurance application, or a regulatory review. The audit output gives you a factual baseline, but remediation may need to be documented, evidenced, and in some cases certified.
    • You are adopting Copilot or other AI services. The AI readiness module will tell you where your gaps are, but closing them — sensitivity labels, access controls, DLP policies — is a project that benefits from experience doing it.

    The point is not to avoid consultants. The point is to arrive at that conversation informed, with a clear picture of what needs to be done rather than starting from a blank page.

    The Checklist Before You Pick Up the Phone

    If you want to understand your M365 tenant before committing to an engagement, here is the minimum viable assessment:

    • [ ] Run the security baseline module and resolve any critical MFA or conditional access findings
    • [ ] Run the admin role module and reduce global administrators to two or three accounts
    • [ ] Run the guest access module and revoke access for accounts no longer needed
    • [ ] Review the SharePoint governance report for externally shared sites and orphaned content
    • [ ] Review the AI readiness output if Copilot adoption is on your roadmap

    If you can work through that list and resolve the findings, your tenant is in materially better shape. If you cannot, you now have a specific, evidenced brief for what needs to happen next.

    The M365 Audit Toolkit is available now on GitHub. It is free, read-only, and built for exactly this use case.

    If you run it and the findings warrant a conversation, the Security & Compliance Strategy service covers M365 tenant configuration as part of a broader engagement. Or get in touch with your report — I can tell you within a 30-minute call whether the gaps are ones you can close yourself or whether it is time to bring in support.

  • Why Dependency Hygiene Becomes a Leadership Issue

    Why Dependency Hygiene Becomes a Leadership Issue

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

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

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

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

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

    The recent GitHub signals were small, but not trivial

    A few examples stood out.

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

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

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

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

    Why senior leaders should care about this work

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

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

    1. Drift increases the cost of every later decision

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

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

    That is when the bill arrives.

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

    2. Poorly classified failures waste leadership attention

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

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

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

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

    3. Handover quality is part of risk control

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

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

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

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

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

    What good leadership looks like here

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

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

    Keep an explicit tolerance for drift

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

    Insist on failure signals that guide action

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

    Ask for handover evidence before calling a project done

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

    Connect maintenance discipline to commercial credibility

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

    That is the commercial expression of dependency hygiene.

    A simple question worth asking this quarter

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

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

    The answer usually reveals more than a tooling audit alone.

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

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

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

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

    Before You Launch an AI Assessment, Fix the Operating Model

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

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

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

    The recent signals are not about polish alone

    One assessment build in particular stood out this week.

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

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

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

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

    An AI assessment is a service, not a content asset

    This is the point many firms miss.

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

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

    They will care about questions such as:

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

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

    The four controls I would design before launch

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

    1. Fallbacks for report generation

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

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

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

    2. Safe rendering and an explicit handoff path

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

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

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

    3. Privacy, GDPR, and role-based access

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

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

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

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

    4. Truthful monitoring and approvals around the edges

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

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

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

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

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

    Where this lands commercially

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

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

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

    A sensible pre-launch checklist

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

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

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

    And in this category, usable beats flashy every time.

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

  • The M365 Security Baseline Most SMEs Skip

    The M365 Security Baseline Most SMEs Skip

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

  • The M365 Security Baseline Most SMEs Skip

    The M365 Security Baseline Most SMEs Skip

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

  • The M365 Security Baseline Most SMEs Skip

    p

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

  • The M365 Security Baseline Most SMEs Skip

    The M365 Security Baseline Most SMEs Skip

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

Powered by