Skip to content

Service · AI agent harnesses

AI agent harnesses for enterprise production systems

Your agents can act on live systems. The harness decides what they may touch, records what they did and lets you stop them, tested before go-live.

An AI agent harness is the engineering around a model that decides which tools an agent may use, checks its output, records what it did and lets a person stop it.

Comonad designs and builds AI agent harnesses for large organisations, inside your estate and your release process, with whichever models your constraints allow. Every harness includes human approval for irreversible actions and a tested way to stop the agent. The same discipline applies to workflow automation behind the interfaces your teams already use.

Tell us which system you want an agent in, and what it should and should not be allowed to do.

  • Platform leads
  • Engineering leads
  • Architecture leads
What is an AI agent harness?

An AI agent harness is everything around the model that makes an agent operable: orchestration, the tools it may call and with what permissions, what it may retain, evaluation, guardrails, logging and a way to stop it. The model provides reasoning; the harness decides what that reasoning is allowed to touch.

A harness for an established enterprise estate adds four things:

  • Boundaries: what the agent may call, on whose authority, and what data never leaves your environment.
  • Structured outputs and defined failure modes, so downstream systems receive something they can validate and reject.
  • Fallbacks and a documented rollback, tested before go-live.
  • Observability that your operations team can use: logs, traces and alerts in the tools they already watch.
Agent harnesses for existing systems

This work is for platform and architecture leads putting agents into an estate that already has users, audit logs and a release process.

The design follows a simple idea from software architecture. Bounded contexts give clear limits on what an agent may call; composition decides how tools, evaluation and guardrails stack on top of each other.

What an engagement includes:

  • Harness design: what the model may call, what it may retain, what never leaves your boundary, and how tools compose.
  • Evaluation before and after release. Evaluations, or evals, are repeatable tests of model behaviour: fixtures, regression sets, structured-output checks and guardrail tests, run as a gate on every change.
  • Access control, key handling, observability, fallbacks and a documented rollback.
  • Handover to the team that will run the change, including how to disable the AI feature and fall back to the previous behaviour.
Workflow automation behind existing interfaces

We automate engineering and business workflows where the output has to be structured and the failure mode has to be defined in advance. The automation runs behind the interfaces your teams and systems already use, so nobody has to adopt a new tool to benefit from it. Each automated step has a schema for its output, a check that rejects anything that does not conform, and a route to a person when the check fails. Operations and product owners keep control: they decide which steps are automated, see what the automation did, and can switch it off.

Bringing AI into how you build software

Setting how a whole engineering organisation uses AI to build software is a separate service, with its own policy, gates and rollout.

AI-enabled SDLC

Engineering and governance together

Agent harness work builds the harness; governance defines what the harness must satisfy. Governance work ends at a written control set and a review of the running system unless implementation is agreed. Agent harness work is where those controls are built: permissions, logging, human approval steps, evaluation gates and the stop control. Many organisations need both, and we scope them separately so that each can be reviewed on its own terms.

Every harness is designed to be governed. See how to govern AI agents in production.

AI governance consultancy

What you keep

  • Harness design

    The tools the agent may call, the permissions, and what is out of bounds.

  • Evaluation suite

    The checks the agent must pass before and after release.

  • Tests and runbooks

    What your team needs to operate and observe the agent.

  • Tested switch-off

    A tested way to stop the agent and fall back to the previous behaviour.

How an engagement runs

What we do not do

  • We do not give legal advice. Legal sign-off stays with your counsel.
  • We do not resell agent platforms or model access.

Who it is for

  • Platform and engineering leads putting agents into an existing estate.
  • Architecture leads who need boundaries, evaluation and a tested way to stop.
Alex Vakhitov, founder of Comonad Limited

Alex Vakhitov

Founder, Comonad · AI and software architect, London

Alex Vakhitov founded Comonad in 2024. An AI and software architect, he was co-founder and CTO of Cloud KB, UK energy-market software, from August 2015 to March 2022.

Questions about AI agent harnesses

What is an AI agent harness?

The layer around a language model that makes an agent operable in production. The model provides the reasoning; the harness decides what the agent may touch, checks what it produces and records what it did, so that a person stays accountable for the result.

How is this different from buying an agent platform?

A platform gives you components. A harness is the design that decides how those components are allowed to behave in your estate: which tools an agent may call, on whose authority, how its output is checked, what is logged and how it is stopped. We can build a harness on a platform you already have, or without one.

Which models do you use?

We use whatever your constraints require: hosted models through an API, or models you already run. We do not lock an engagement to a single vendor. Data-handling rules, data residency and cost often narrow the choice. The harness, the evaluation and the controls matter more than the brand on the model card, and they should survive a change of model.

How do you stop an agent safely?

Every harness has a documented way to disable the agent and fall back to the previous behaviour. The switch is tested before go-live, irreversible actions need human approval, the credentials the agent uses can be revoked independently, and the runbook sits with the team that operates the system.

Do you build inside our stack and hand over?

Yes. The work follows your release process and runs in your environment, and your team is involved from design onwards, so nothing at handover is new to them.

Will you train a model on our data?

Not by default. Usually the work is retrieval, tooling, evaluation and access control around a model you already have a licence to use. Fine-tuning is only in scope if you ask for it and the data-handling rules are written down first, including what data is used, where it is processed, who can access the result and how long it is kept.

Related

Discuss an agent harness

Tell us which system you want an agent in, and what it should and should not be allowed to do.

Discuss an agent harness