The AI agent is not the product

There is a live discussion on X right now about Claude Code, coding agents, context compaction, sandboxes, tool calls and agent infrastructure.

At first glance, that sounds like tool-specific engineering chatter.

For companies, it points to something much more practical: a production AI agent is not simply a good model with access to a few tools.

A production AI agent is a system.

And like any serious system, its quality is not determined only by the intelligent core. It is determined by the architecture around that core: what information the agent can see, which actions it can take, how tool calls are validated, who can inspect what happened, when a human must approve a decision, and how mistakes are stopped, rolled back or investigated.

The agent itself is only part of the product.

The rest is the harness: the runtime environment that makes the agent reliable, bounded, observable and useful.

Why this matters now

Many teams have already passed the first phase of AI adoption.

They have tried ChatGPT, Claude, Cursor, Copilot, Replit, Lovable or similar tools. They have seen AI write code, generate components, summarize documentation and explain bugs. Some have seen how quickly a prototype can be assembled.

Now the second phase is starting.

The question is no longer just: can the model solve this task?

The question is: can we safely embed this capability into our everyday delivery, our products and our internal operations?

That is a different kind of problem.

A chat response can be wrong and still be harmless. An agent with repository access, customer data, deployment permissions or write access to internal tools is different. In that context, it is not enough for an answer to sound plausible. The whole system has to be accountable.

The common mistake: model equals system

Many AI discussions focus on models.

Which model is better? Which one is faster? Which one has the larger context window? Which one writes cleaner code? Which one is cheaper?

Those questions matter. But they are not enough.

In a production agent workflow, the model is one component. It does not determine reliability on its own. It works inside an environment that selects context, exposes tools, checks responses, executes actions and stores results.

If that environment is weak, even a strong model can only help so much.

Typical problems look like this:

• The agent receives too much context and confuses relevant information with noise.
• Tools are over-permissioned and allow more than the task requires.
• Tool calls are not validated properly.
• Failed actions are retried automatically when a human should inspect them.
• Logs show only the final action, not why the agent made the decision.
• A successful prototype is moved directly into an operational process.

The problem is not simply “AI is unreliable”.

The problem is that the agent was not designed as a production system.

What an agent harness needs to do

The word harness sounds technical, but the idea is simple.

A harness is the structured environment in which the agent operates. It connects the model, context, tools, rules, validation, security and operations.

For client-facing software or internal business processes, that harness should do at least seven things well.

1. Control context deliberately

AI agents depend on context. But more context is not automatically better.

An agent needs to know what matters for the current task. It does not need every file, every Slack message, every ticket and every old decision.

Good context is curated.

That means:

• clear sources;
• traceable provenance;
• separation between trusted and untrusted information;
• limited exposure to sensitive data;
• deliberate summaries instead of arbitrary history;
• rules for retention and forgetting.

Context compaction and persistent memory features are useful. They are also architecture decisions. If important details are lost, or false information is compressed into a neat summary, the agent may later work from a clean-looking but damaged view of the system.

2. Treat tools like APIs

An agent that uses tools is effectively a client for internal APIs.

It reads files, opens tickets, queries databases, creates pull requests, starts deployments or writes into systems.

Those tools should not be treated as loose helper functions. They need contracts.

Good tool design answers:

• Which inputs are allowed?
• Which outputs are reliably structured?
• What errors can occur?
• Which actions are reversible?
• Which actions require approval?
• Which data may be returned in which context?

If tool calls are only roughly defined, subtle failures become hard to see. The model may call the right tool with slightly wrong parameters. It may interpret the response incorrectly. It may receive too much data and build a plausible but false decision on top of it.

For production systems, “it usually works” is not enough.

3. Keep permissions narrow

The most important security rule for agents is boring and proven:

Least privilege.

An agent should only have the permissions it truly needs for the current task. Not every possible task. Not the most convenient workflow. Not whatever was useful during the demo.

For software development, that can mean:

• read access to defined areas of a repository;
• write access only on working branches;
• no direct access to secrets;
• no production deployments without approval;
• separate roles for analysis, change, review and release;
• time-limited permissions.

For internal tools, it can mean:

• customer data only in the required fields;
• write operations only after explicit confirmation;
• no combination of “read everything” and “change everything”;
• audit logs for every tool call.

An agent does not need a blanket mandate to be useful. It needs good boundaries.

4. Put validation between model and action

A model can express intent. A production system has to check actions.

Between “the agent wants to do X” and “X actually happens”, there should be a validation layer.

That layer checks things like:

• Is the tool call syntactically valid?
• Do the parameters match the allowed schema?
• Does the action change critical data?
• Is the change within the expected scope?
• Are there tests or checks that must run first?
• Does a human need to approve it?

This is especially important because many agent failures do not look dramatic. They are small deviations: the wrong file, the wrong customer, the wrong filter, the wrong assumption about a state.

Good validation prevents small model mistakes from becoming real system mistakes.

5. Build observability from the start

When a normal backend service fails, teams need logs, metrics and traces.

Agents are no different. If anything, they need this more.

A team should be able to understand:

• Which context did the agent use?
• Which tools were called?
• Which data came back?
• Which decision was derived from that?
• Which action was executed?
• Who approved it, and when?
• What was retried automatically?

Without this information, debugging becomes guesswork. You see the outcome, but not the chain that produced it.

For companies, this is not only a technical concern. It affects trust, compliance, support and accountability.

6. Plan fallbacks and rollback

Agents will make mistakes.

The right question is not whether every mistake can be prevented. The right question is whether a mistake stays contained.

A good agent harness therefore has clear fallbacks:

• stop instead of continuing into risk;
• hand off to a human;
• return safe default responses;
• retry only for genuinely transient failures;
• separate staging and production paths;
• rollback for changes;
• clear incident trails.

This is the difference between experimental automation and production automation.

A demo agent is impressive when it keeps going by itself.

A production agent is impressive when it stops at the right moment.

7. Put the human in the right place

Human-in-the-loop should not be theatre.

If every step needs manual confirmation, the agent is slow. If no human ever needs to intervene, the risk is often too high.

The useful point sits between those extremes.

Routine, reversible and well-validated actions can run automatically. Critical, irreversible or ambiguous decisions need human approval. Product decisions, architecture changes, customer data, payments, deployments and legally relevant workflows should have clear ownership.

A good agent does not replace responsibility.

It makes some work faster while keeping responsibility visible.

What this means for founders and CTOs

For founders, product owners and CTOs, the practical lesson is simple:

Do not evaluate AI agents only by the demo.

A demo shows what is possible. Architecture shows whether it is sustainable.

Before using agents in real processes, teams should answer a few questions:

• What task should the agent actually own?
• What data does it need?
• What data must it explicitly not see?
• Which tools may it use?
• Which actions may it execute by itself?
• Which actions require review or approval?
• How are errors detected?
• How is a wrong result reversed?
• Who is responsible if something goes wrong?

These questions do not slow AI down. They make it usable.

Why this matters for serious business software

Many companies do not need AI theatre.

They need systems that work: customer portals, internal tools, operational workflows, integrations, reporting, back-office automation and maintainable software.

Agents can be very valuable there. They can gather information, reduce routine work, operate interfaces, improve internal tooling and speed up software delivery.

But serious businesses rely on trust, process and continuity. An agent that looks impressive but cannot be controlled does not fit that environment.

That is why agent architecture matters more than the model headline.

Where McDougall Digital can help

At McDougall Digital, we do not treat AI agents as magic. We treat them as software with unusual properties.

That is an advantage.

It means they can be designed like software: with system boundaries, data models, permissions, tests, review processes, deployment rules, monitoring and clear ownership.

We help teams with things like:

• reviewing existing AI workflows for production risks;
• separating strong agent use cases from risky automation;
• modelling context and data access properly;
• designing tool contracts and permissions;
• building review, test and approval flows;
• implementing internal agents or AI-supported development systems in a maintainable way.

The point is not to sell as much autonomy as possible.

The point is to create real leverage without losing control, security or product quality.

The core message

An AI agent is not just a model.

It is a production system made of model, context, tools, permissions, validation, observability and human responsibility.

If you only evaluate the model, you miss the part that decides whether the agent becomes useful or risky in day-to-day operations.

The current discussion around Claude Code, context compaction and agent harnesses shows something important: the next quality jump in AI development will not only come from better models.

It will come from better architecture around the models.

Next step

If you are considering AI agents for software development, internal tools or operational workflows, it is worth doing an architecture check before a broad rollout.

McDougall Digital can help define the right boundaries, tools, approvals and operating rules before a strong prototype becomes a system that is hard to control.