The Human Should Not Be the Integration Layer

AI can produce a good answer in seconds.

Then a person has to carry it into the work.

The person copies the code into a repository. They move the requirement into a ticket. They bring the ticket into a design conversation. They explain the change to engineering. They run the result, inspect what broke, and return to the AI with the feedback.

The answer was fast.

The workflow was not.

I wrote about this problem in Give AI What Only You Can Give It. Before our tools became more integrated, the person using AI had to keep the product artifacts connected. The human became the integration layer.

That is a useful place to begin. It is also a terrible place to stop.

The next leap in AI-native work is not another improvement to the answer. It is removing the person from the mechanical relay between steps.

This requires two kinds of engineering.

Harness engineering puts intelligence where the work happens.

Loop engineering helps that intelligence move bounded work through execution, validation, correction, verification, and approval.

They are different ideas. In practice, I do not think they make sense as separate articles. Once AI enters a workflow, another question follows immediately. Can it carry the work forward without turning the human into the relay again?

The assistant beside the work

Most AI use still begins outside the workflow.

You have a product problem, an engineering problem, or a customer question. You leave the system where the work lives and open a chat. You reconstruct enough of the situation for the AI to help. Then you take the answer somewhere else.

Work
    -> Explain the work to AI
    -> Receive an answer
    -> Move the answer back into the work
    -> Test or review it
    -> Explain what happened to AI

This can make one task dramatically faster. It does not necessarily make the larger workflow faster by the same amount.

The human is still responsible for:

• noticing when AI should be involved;
• collecting the relevant context;
• moving the output into the right system;
• triggering the next step;
• checking routine defects;
• describing failures back to the AI;
• keeping later artifacts aligned with earlier decisions.

The person is not only exercising judgment. They are also operating the connections.

That distinction matters.

Human judgment is valuable. Human copy-and-paste is not a control system.

Harness engineering puts intelligence inside the workflow

Harness engineering changes where AI operates.

Instead of visiting AI in a separate interface, we place it at a specific point where the work already happens. It receives the context for that job, can use the relevant tools, and produces an output that the workflow knows how to handle.

A common example for software engineers is a harness around a code repository.

It usually begins with an AGENTS.md file or similar repository guidance. The goal is straightforward: explain how to get started, just as you would when onboarding a developer to the codebase.

A fresh agent run often arrives like a new developer on day one. It needs the repository structure and build process. It also needs the right commands and local rules.

Software teams already have patterns for communicating this information:

• README.md files;
• contribution guides;
• architecture documents;
• development and test commands;
• repository conventions;
• project-specific constraints.

Historically, teams have been inconsistent about maintaining these documents. They should have maintained them for people. Agents make the omission harder to ignore.

Without that knowledge, the agent is working blind. It can search the repository and infer patterns, but it spends time rediscovering what the team could have stated directly. It may also mistake an accidental pattern for an intentional rule.

The first version of the harness therefore helps the agent understand the codebase efficiently.

It does not stay limited to the repository for long.

The workflow extends beyond the code

A software developer does not begin with code. They begin by understanding what they are building and why.

That information often lives elsewhere. A team may keep product and architectural knowledge in a wiki such as Confluence. If the project is large enough, its current implementation state may live on a ticket board such as Jira.

Those systems are not optional background once an agent is doing real work. They are part of the agent's working context.

The harness has to let the agent retrieve that context when the work requires it.

Repository guidance
    -> Understand how the codebase works
    -> Retrieve product and architecture context from the wiki
    -> Read current work and ownership from the ticket board
    -> Select or create the right unit of work
    -> Implement with the current goal and team state in view

This access should not depend on a person noticing every missing piece and pasting it into a conversation. When the agent realizes it needs more information, it should know where to look and have permission to retrieve the appropriate context.

The ticket board matters for coordination as well as requirements. The agent needs to see what is already assigned or in progress. Otherwise, it may clobber work another person or agent is doing. Depending on its authority, it may also select, assign, or create a ticket.

Once the repository, wiki, and work board are connected, the agent can approach implementation with much more confidence. It understands the purpose and current state of the work. It also sees the codebase boundaries and nearby work already in motion.

That is why I consider this a harness.

It is not merely a wrapper around a model. It gives the agent the context and access paths needed to participate in the real workflow. A human no longer has to carry every piece of the work to it.

Repository + wiki + ticket board
    -> Harness gathers the relevant context
    -> AI performs a bounded job
    -> Result returns inside the workflow

This is more than convenience.

The harness removes a context transfer. It gives the AI a defined job, a known environment, and access to the evidence around the work.

The intelligence is no longer waiting in another room.

It becomes part of how the workflow moves.

Start with an operator, not an automatic trigger

Having the harness in place does not mean the agent should begin work whenever something changes.

My recommendation is to start with the whole path prepared but keep the trigger manual.

That is what I do. I tell the agent to work on a specific ticket, then stay beside it while the cycle runs. I watch what it does and pay attention to the places where it needs to escalate.

Operator selects the work
    -> Agent gathers context through the harness
    -> Agent executes the cycle
    -> Operator observes decisions and escalations
    -> Loop is refined before more authority is added

This is not wasted supervision. It is how the operating process becomes trustworthy.

You learn which context is missing and which decisions are routine. You also see which failures are safe to correct and where the agent makes wrong assumptions. Those lessons belong in the loop before the trigger becomes automatic.

A harness can still leave the human in the middle

Embedding AI is not the end of the problem.

A harness can draft a ticket, generate a test, or make a code change. Someone may still need to inspect the output and decide what failed. They may then have to explain the failure, trigger another attempt, and move the result forward.

The human is no longer carrying the original answer into the workflow. They are carrying the feedback around inside it.

AI produces work
    -> Human inspects it
    -> Human explains the failure
    -> AI tries again
    -> Human inspects it again
    -> Human moves it forward

I ran into this through validation.

You should not trust AI output merely because it arrived quickly or looked convincing. At first, I inspected the work myself. I judged it against the criteria and gave the feedback back to the AI.

That worked until AI became fast enough that my review was the slowest part of the system.

I had removed one bottleneck and made myself the next one.

The answer was not to remove validation. It was to make more of the validation explicit.

The AI needs access to its own output and a definition of acceptable work. It also needs to know what to do after a failed check. Then it can inspect and improve routine work before bringing the result to me.

That is where harness engineering becomes loop engineering.

Loop engineering feeds the output back into the work

Loop engineering comes from an old engineering idea.

A feedback loop helps stabilize a system by feeding its output back into its input. The system observes what happened, compares that result with the intended state, and uses the difference to decide what should happen next.

That is the purpose of loop engineering with agents.

A harness gives AI a place in the workflow. A loop lets it carry a bounded outcome through the process, observe the result, and bring what it learned back to the beginning.

The system needs more than a model and a tool call. It needs a contract for the work.

The loop must know:

• the outcome it is trying to achieve;
• the context it may use;
• the steps or transitions in the process;
• the systems and tools it may touch;
• the skills and rules it should apply;
• how to validate the work;
• how to respond when validation fails;
• how to verify the result in the real system;
• where human approval is required;
• when it must stop and escalate;
• what should be recorded for the next run.

New context or request
    -> Select the bounded loop
    -> Gather the permitted context
    -> Use tools and skills
    -> Produce the work
    -> Validate the output
        -> If routine failure: correct and retry
        -> If consequential uncertainty: stop and escalate
    -> Verify the result
    -> Observe what happened
    -> Feed the evidence into the next decision

This is not autonomy for its own sake.

The goal is not to let an agent do anything. It is to execute a known process within clear boundaries. The system must then prove that the work is ready for the next consequence.

A useful loop does not hide responsibility.

It makes responsibility clearer.

The loop does not end when the code is written

Consider a product feature.

The work begins with understanding users and capturing the product specification. People should still talk to users and develop the human understanding behind the product. That contact with reality remains one of the most valuable human responsibilities.

Once the information has been gathered, much of the processing should not require a human relay.

An agent can parse the transcript and extract valuable information. It can compare that evidence with existing architectural decisions, update the specifications, and create or revise the implementation tickets.

For an AI-native company, it may make sense to keep more of this operating context inside the repository. The agent is doing much of the processing and moving the information where it needs to go. Splitting it across many systems adds little value unless the wider business process requires those systems.

The agent can then implement the feature. But completed code is not the measured outcome.

The work has to be checked, tested, deployed, and tested again in production. Only then can we observe how the system and the product are actually behaving.

User reality
    -> Transcript and evidence
    -> Product specification
    -> Architectural decisions
    -> Tickets and implementation
    -> Tests and review
    -> Deployment
    -> Production verification
    -> System and product observability
    -> Analytics
    -> New evidence enters the next product decision

That is an end-to-end loop.

Do not rebuild the infrastructure we already have

Software engineering already has strong infrastructure for testing and deployment.

Continuous integration and continuous delivery existed long before modern coding agents. We should use those systems rather than ask an agent to improvise weaker replacements.

The agent can help create and improve the tests, workflows, and deployment configuration. It can use the existing CI/CD system to move work through known gates. Its job is to participate in good engineering practice, not bypass it.

The same is true after deployment.

A feature needs observability. We need to know how the system behaves in production and how people use what we built.

Technical observability can show:

• errors and failures;
• performance and bottlenecks;
• resource behavior;
• reliability in production.

Product and business observability can show:

• which features people use;
• how often they use them;
• where they drop off;
• when they stop using them;
• whether the intended outcome occurred.

Observability is often skipped because adding it takes time. Agents make it much cheaper to include as part of implementation.

That matters because observability enables the analytics that close the loop.

The same agent that understood the feature and helped implement it can read the resulting system and product analytics. It can identify an error, bottleneck, drop-off, or unused feature. That evidence can feed the ticketing system or return to product discovery for more understanding.

Implementation
    -> Production behavior
    -> Observability
    -> Analytics
    -> Research or ticket
    -> Next implementation cycle

Now the output has become an input.

The loop is closed.

This is the larger pattern behind the Product Development Factory in The Collapse of the Middle. Client context enters the system, becomes tickets and implementation, moves through validation, and remains visible through operator status. The next evolution is letting observed results feed the following cycle.

Automate the trigger last

Once the full loop exists, keep running it with an operator.

The operator will see where the workflow needs more context, better criteria, a narrower boundary, or a different escalation. The loop should mature under observation before the human stops monitoring every run.

When confidence is high, the loop can graduate to automatic triggers.

A trigger might be:

• a ticket assigned to the agent;
• a wiki article or approved requirement changing;
• a tagged client meeting or feature discussion;
• a production error crossing a threshold;
• a product metric showing an unexpected drop-off.

The trigger does not have to authorize the entire loop.

A production error might trigger research and documentation, then alert a person. A more mature loop might also prepare a fix and validate it without merging the change. A highly trusted loop could move further, but consequential actions can still remain behind approval gates.

The question is not merely whether the loop starts automatically.

The question is how far it may go before a human must decide.

The human leaves the relay and moves to the control surface.

Closing the loop does not mean removing the human

The phrase human in the loop is often treated as if there are only two choices.

Either a human approves everything, or the AI is autonomous.

That is too crude.

A good system distinguishes different kinds of human involvement.

Humans define the outcome

The AI cannot decide which future is worth building. People still own the goal, the customer promise, and the acceptable tradeoffs.

Humans define the boundaries

People decide which systems the loop may touch and which actions require approval. They also decide which failures can be corrected automatically and which uncertainty must stop the work.

Humans design the judging criteria

Routine validation can only move into the loop after someone has made quality legible. The system needs tests, policies, examples, acceptance criteria, or other evidence it can inspect.

Humans make consequential judgments

A test can tell us whether software behaves as specified. It cannot tell us whether we specified the right product, accepted the right risk, or made the right promise to a customer.

Humans remain accountable

If the loop causes harm, “the AI did it” is not an operating model. People remain responsible for the system, its authority, its consequences, and whether it deserves continued trust.

The point is not to remove the human from the loop.

The point is to stop putting the human between every step of it.

Validation and verification are not the same

A loop also needs to distinguish validation from verification.

Validation asks whether the work meets the defined criteria.

Verification asks whether the intended result actually exists in the real system.

For software, validation might include tests, static checks, policy checks, or review against acceptance criteria. Verification might mean confirming that the change was deployed and behaves correctly in the target environment.

A loop that writes code and reports success because the code looks plausible has not closed the loop.

A loop that runs a test but never checks whether the approved change reached production has not closed it either.

This distinction appears outside software too.

A system may validate that a proposal contains all required sections. Verification asks whether the approved proposal exists in the right place and reflects the current account context. It must also be ready for the person authorized to send it.

The loop ends at the real consequence, not at the model output.

Find where you are acting as the integration layer

You do not need to automate an end-to-end organization to begin.

Choose one repeated workflow where AI already helps you. Then map every place where a person carries information, output, or feedback between steps.

## Outcome
What meaningful result is this workflow trying to produce?

## Current relay
- Where does someone leave the work to consult AI?
- What context do they manually reconstruct?
- Where do they paste or re-enter the output?
- What next step do they trigger by hand?
- What routine defects do they inspect?
- How do they return failure feedback to AI?

## First harness
- Where can AI operate inside the existing workflow?
- What bounded job can it own there?
- Which context and tools does that job require?
- How can a person inspect the output safely?

Once the harness is legible, define the feedback loop and its trigger boundary.

## Smallest trustworthy loop
- What criteria define acceptable work?
- Which failures may trigger an automatic retry?
- Which uncertainty must stop and escalate?
- What needs verification in the real system?
- Which signals show what happened?
- How will that evidence feed the next decision?
- Where is human approval required?
- What record should remain afterward?

## Trigger maturity
- Which operator starts the loop today?
- What should the operator watch while it runs?
- What evidence would make an automatic trigger trustworthy?
- If triggered automatically, how far may it go before approval?

Do not begin with broad autonomy.

Start where the context is available and the job is bounded. Make sure the output is easy to inspect and the consequence is understood.

Then make one human relay unnecessary without making human judgment invisible.

The next bottleneck is organization

Once useful harnesses and loops exist, another problem appears.

A company may have many outcomes, repositories, tools, and working systems. One giant agent should not own all of them. The work needs clear boundaries, ownership, routing, and coordination.

That is where outcome agents and system agents enter the series.

But the foundation comes first.

AI has to move from a place we visit to intelligence inside the work. Then it has to carry bounded work far enough to validate, correct, verify, and ask for judgment at the right moment.

The human should understand reality, choose the outcome, define the boundaries, and remain accountable for the result.

The human should not be the integration layer.

If you want guidance on getting started, email me at rick@datasaa.com. I would also be glad to compare notes on engineering agents, the SDLC, and the end-to-end product lifecycle.