Skip to content
Comonad

AI engineering for enterprise production systems

Comonad designs and builds AI agent harnesses: the orchestration, tool permissions, evaluation and guardrails around large language models. We apply the same discipline to AI in the software development lifecycle (SDLC) and to workflow automation. We work inside systems that already have users, audit logs and a release process, and you keep the ability to switch the AI feature off. We take on AI engineering engagements selectively, and each one draws on our own R&D on agent harnesses, the AI-assisted SDLC and automation, and on operating our own products.

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

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.

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.

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.

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.

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

AI-assisted SDLC with quality gates

An AI-assisted SDLC uses AI across specification, code generation, review, testing, CI/CD and release, with a quality gate at each step so that generated work is checked before it moves on. The emphasis is on the gates and the evidence they produce, whichever coding assistants your teams use.

The gates, in plain terms:

  • Specification review: a person agrees what is being built before anything is generated.
  • Review of generated changes, against the same standards as any other change.
  • Automated tests and evals that generated work must pass before merge.
  • Release checks that apply whether a change was written by a person or with AI assistance.
  • A record of which changes were AI-assisted, so that audit and incident review still work.

This work is for engineering leaders introducing AI across teams who need quality gates and evidence on generated work.

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.

How an engagement works

  1. We start from the system you already operate: its interfaces, data classes, release process and the cost of a wrong answer.
  2. We write the scope down first: the model, the tools it may call, the evaluation it must pass, and what is out of bounds.
  3. Implementation follows your release process. We do not require a rewrite of the surrounding application.
  4. You keep the tests, the runbooks and the ability to switch the AI feature off.

Engineering and governance together

Engineering 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. Engineering is where those controls are built: permissions, logging, human approval steps, evaluation gates and the stop control. Many engagements need both, and we scope them separately so that each can be reviewed on its own terms.

AI governance consultancy

Questions about AI engineering

What is an AI agent harness?

An AI agent harness is the layer around a language model that makes an agent operable in production: orchestration, the tools it may call and with what permissions, what it may retain, evaluation, guardrails, logging and a tested way to stop it. The model provides the reasoning; the harness decides what that reasoning may touch. Prompting on its own does not provide any of these controls.

How do you put AI agents into an existing production system safely?

Define the boundary first: which tools the agent may call, which data it may see, and on whose authority it acts. Build evaluation and guardrails before release. Ship through your normal release process behind a switch, log every action the agent takes, and keep a rollback that has been tested. The team that owns the system should be able to operate it without us.

What is an AI-assisted SDLC?

An AI-assisted software development lifecycle uses AI across specification, code generation, review, testing, CI/CD and release, with a quality gate at each step so that generated work is checked before it moves on. It also records which changes were AI-assisted, so that audit and incident review still work. The gates and the evidence matter more than the choice of coding assistant.

Do you replace our platform team?

No. We work with the team that owns the system, so that they can release, observe and disable the AI feature without us in the loop. Implementation follows your release process, and at handover your team keeps the tests, the runbooks and a documented, tested way to switch the AI feature off and fall back to the previous behaviour.

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.

Will you train a model on our data?

Not by default. Most of 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.

How long does an engagement take?

Scope and duration are agreed after a short discovery call, because they depend on the system. An engagement might be one controlled endpoint, a harness with several tools, or a quality-gate programme across the software development lifecycle. Either way, the scope and milestones are written down before any production code, so you know what will be delivered and when.

How do we turn the AI feature off?

Every engagement hands over a documented way to disable the AI feature and fall back to the previous behaviour. The switch is tested before go-live, the runbook sits with the team that operates the system, and credentials used by the AI component can be revoked independently. If an AI feature cannot be turned off quickly, it is not ready for production.

Related

Discuss an engagement

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

Book an introductory call