Why I believe AI coding agents need an infrastructure layer.

Yes — I think verification should be a first-class primitive, explicitly separate from execution.

A quality gate usually asks, “Did the result pass these checks?” Verification asks a different question:

“Is the result still correct after the change, and was that conclusion reached independently?”

That distinction matters in multi-agent pipelines because otherwise you can get:

Agent A executes → Agent A verifies → Agent B builds on A's verification → silent regression

For NAEOS, I’d model the lifecycle more explicitly:

Intent → Policy Decision → Execution → Independent Verification → Evidence → Finalization

The verification stage should have its own identity, context, and evidence boundary. Ideally, the verifier doesn't inherit the executor's reasoning as its source of truth. It gets the relevant requirements, policy, resulting artifacts, and test evidence, then evaluates them independently.

I also think policy should be able to specify verification requirements, not just execution permissions.

For example:

• low-risk change → automated verification
• medium-risk change → independent agent verification
• high-risk change → independent verification + human approval
• critical production action → independent verification + explicit authorization

So verification isn't simply “downstream of the quality gates.” The policy determines when verification is mandatory, what independence means, and what evidence is required before the action can be considered complete.

That gives us another important invariant:

An agent cannot establish the validity of its own consequential work merely by declaring it verified.

That feels especially important once multiple agents start collaborating in the same engineering pipeline.

Exactly. I think you've identified one of the hardest parts.

If policy is just prose that the agent is expected to interpret, we haven't really solved the problem — we've just moved the ambiguity from the codebase into the governance layer.

That's why I'm thinking of policy in NAEOS more like a machine-readable engineering contract than a document.

A policy should be able to express things such as:

scope → allowed capability → constraints → required evidence → approval level → enforcement point → audit requirements

Then the agent can reason about the policy, but the agent's interpretation shouldn't be the final authority. The policy engine evaluates the proposed intent/action against the contract.

That also gives us a useful separation:

Agent: “I want to do X because I believe it is necessary.”

Policy engine: “Under policy version Y, X is permitted/not permitted, and these conditions must be satisfied.”

Audit layer: “Here is the evidence showing what actually happened.”

So I agree that precision determines whether this becomes essential infrastructure or just overhead.

The design goal should be to make the governance path more deterministic than the agent's reasoning, while keeping the policy expressive enough to represent real engineering constraints.

That balance is probably one of the central engineering problems NAEOS has to solve.

Exactly. I think that’s a much better first demo than trying to prove vendor neutrality with a large matrix of agents.

One repo, two different coding agents, one shared NAEOS policy.

Start both agents on a task where they legitimately plan to use dependency X. Then, halfway through, change the policy to disallow X.

The key test is not simply whether the final CI catches the dependency. It’s whether NAEOS can detect that both agents' existing plans/actions have become stale under the new policy, regardless of which agent generated them.

Ideally the flow becomes:

Agent → Intent/Plan → NAEOS Policy → Action → Policy Change → Re-evaluation → Block/Require Re-plan

If Agent A and Agent B both get stopped or forced to re-plan through the same governance layer, while their underlying agent runtimes remain unchanged, that makes the vendor-neutral claim tangible.

It also demonstrates something CI alone doesn't: governance can change while work is already in flight, and previously valid agent decisions don't automatically remain valid.

I’d probably make this the first NAEOS proof-of-concept.

The first real failure is usually not that the team has inconsistent tools. It’s when the agents are standardized, the CI is standardized, but the engineering decisions are still implicit and non-deterministic.

For example:

An AI agent can generate code that passes tests and CI, but it may violate architectural boundaries, introduce an unsafe dependency, bypass an engineering convention, or make a decision that another agent would handle differently.

At that point, adding more CI checks or standardizing the agent configuration only treats individual symptoms.

The team needs a system that defines:

intent → policy → capability → action → validation → audit

That’s where I see NAEOS becoming necessary.

So I’d describe the trigger as:

The first real failure is when “the code passed CI” is no longer equivalent to “the engineering decision was acceptable.”

NAEOS is intended to provide the missing control layer between AI agent capability and organizational engineering policy — rather than replacing the existing agents or CI tooling.