DEV Community: bayu priatno

NAEOS Technical Build Log #002 Intent Is Not Authority

bayu priatno — Thu, 24 Sep 2026 16:03:08 +0000

One assumption keeps appearing in AI agent systems:

If the model understands what needs to be done, it can decide what should be done.

I don't think those are the same problem.

An AI coding agent can produce an excellent plan.

It can understand the repository.

It can identify the required files.

It can even correctly predict the command that needs to be executed.

But none of that means the agent is authorized to execute the action.

This distinction is becoming one of the core ideas behind NAEOS:

Intent ≠ Authorization

The model produces intent.

A policy system determines whether that intent is allowed.

The runtime executes an authorized action.

And observation verifies what actually happened.

So the flow becomes:

Agent → Proposal → Policy → Authorization → Runtime → Observation

This sounds like additional complexity.

But consider what happens without the separation.

An agent receives:

“Update the production configuration.”

The model decides:

“I need to modify this configuration file and restart the service.”

What prevents the model from deciding that the restart is also allowed?

Prompt instructions?

System messages?

A policy file inside the context?

Those mechanisms can influence the model.

They don't necessarily constitute an independent authorization boundary.

That's the problem I'm trying to address with NAEOS.

The model should be able to propose an action without becoming the authority that approves the action.

This also creates a cleaner audit model.

Instead of:

Agent said it was allowed.

we want:

Policy P-014 authorized capability C-003 under version V-2.

Then:

Runtime executed C-003.

Then:

External observation produced receipt R-8291.

Now the system can distinguish what was proposed, what was authorized, what was executed, and what was actually observed.

That's a very different trust model.

I'm currently implementing and testing these ideas in NAEOS as an open-source engineering layer around AI coding agents.

The interesting question for me isn't:

“How do we make agents more obedient?”

It's:

“How do we design the system so obedience isn't the security boundary?”

Repository:
https://github.com/NAEOS-foundation/naeos

How are you currently separating agent intent from actual authorization in your AI systems?

I’m Building the Governance Layer for AI Coding Agents — Here’s What I’ve Learned

bayu priatno — Wed, 23 Sep 2026 20:59:15 +0000

I’m building NAEOS (Nusantara AI Engineering Operating System) as an open-source, vendor-neutral engineering layer around AI coding agents.

The problem I’m trying to solve is becoming increasingly obvious as coding agents become more capable:

The model can write the code. But who decides whether the action is actually allowed?

Today, an AI coding agent can:

inspect a repository
create or modify files
install dependencies
execute commands
change configuration
call external tools
open pull requests
trigger CI/CD workflows

The model may have enough context to propose these actions.

But context is not authority.

The architecture I'm testing

The core separation I'm working toward is:

Model proposes → Policy decides → Runtime executes → Observation verifies

This sounds simple, but it changes how you design an AI engineering system.

The model shouldn't be the final authority.

For example, imagine an agent receives this task:

Add authentication using dependency X.

The agent creates a plan and starts implementing it.

Halfway through the work, the engineering policy changes:

Dependency X is no longer permitted.

A normal coding-agent workflow may still have the old plan sitting inside the agent's context.

The important question becomes:

Does the system re-evaluate the action against the current policy before execution?

That's one of the experiments I'm interested in with NAEOS.

Information state is not authorization

I've also been thinking about something related to AI memory and project knowledge.

A document can be:

CURRENT
LEGACY
UNKNOWN
STOP

But that status alone isn't enough.

A document can be current and still not authorize an action.

So NAEOS treats these as different concepts:

Information

What does the system know?

Policy

What is currently allowed?

Authorization

What capability has actually been granted?

Execution

What did the runtime actually do?

Observation

What evidence do we have that the expected side effect occurred?

This distinction is important because an audit log should not simply become a transcript of what the agent said happened.

Audit should outlive the agent

One of the design principles I'm exploring is:

An audit trail should outlive agent memory.

If an agent says:

“I deployed the application successfully.”

that is not necessarily sufficient evidence.

The system should ideally be able to distinguish:

Decision

The action was authorized.

Execution

The runtime actually executed it.

Observation

The external system returned evidence of the resulting state.

For example, a deployment provider ID, resulting health status, rollback status, or another externally verifiable receipt.

That gives us a much stronger model of trust than simply storing the agent's reasoning or conversation history.

Why vendor neutrality matters

I'm deliberately not designing NAEOS around a single coding agent.

The same engineering policies should ideally work across:

GitHub Copilot
Claude Code
OpenAI Codex
Cursor
Gemini CLI
OpenCode
Cline
Roo Code
and other Markdown/instruction-driven agents

The agent is replaceable.

The engineering governance shouldn't be.

That's why I describe NAEOS as an engineering layer around AI coding agents, rather than another coding agent.

One experiment I'm building toward

One of the tests I'm particularly interested in is:

One repository. Two different coding agents. One governance layer.

Both agents receive the same task.

They can produce different plans.

Then the policy changes while the work is in progress.

The question isn't whether the models notice the change.

The question is:

Can the governance layer prevent a now-invalid plan from becoming an authorized action?

If it can, we have something more interesting than better prompting.

We have an engineering control.

Where NAEOS is today

NAEOS is currently an open-source project, and I'm developing the architecture around:

Governance
Engineering constitutions
Policy
Runtime
AI agents
Extensions/plugins
Verification
Audit/event infrastructure
Protocol-neutral handoffs

The repository is public:

https://github.com/NAEOS-foundation/naeos

I'm particularly interested in feedback from people working on:

AI agents
developer tools
distributed systems
authorization systems
platform engineering
infrastructure
software supply-chain security
AI safety/controls

I'm not looking for people to simply agree with the architecture.

I'd rather find the places where it breaks.

If you were designing the control plane for AI coding agents, what would you enforce outside the model?

NAEOS Is Built. Now I'm Looking for the Engineers Who Want to Build the Next Layer.

bayu priatno — Sat, 19 Sep 2026 20:51:47 +0000

I'm not writing this post to announce another AI coding tool.

I'm writing it because NAEOS has reached the point where I don't want to build it alone anymore.

The repository is public.

The architecture is documented.

The core platform is running.

There is real code, not just a pitch deck.

And now I'm looking for engineers who want to help decide what this project becomes next.

NAEOS GitHub Repository

What Is NAEOS?

NAEOS stands for:

Nusantara Engineering & Architecture Operating System

The current repository describes NAEOS as a declarative engineering platform built around the idea:

Specify Once. Build Anywhere.

The core idea is simple:

Instead of allowing software projects to accumulate disconnected specifications, code, documentation, AI instructions, governance rules, and deployment artifacts, NAEOS attempts to create a common engineering model from which these artifacts can be derived and validated.

The repository currently contains components for:

specification parsing
NEIR — NAEOS Engineering Intermediate Representation
validation
deterministic pipeline execution
code generation
AI context compilation
AI-agent adapters
governance and policy
audit
MCP integration
profiles
templates
plugin marketplace
WASM plugin runtime
testing
documentation generation
migrations
observability
distributed execution

The current public repository is a substantial Go codebase with hundreds of commits and an active development roadmap.

This is important:

I'm not looking for someone to help me start a repository.

I'm looking for people who want to help turn an existing foundation into something much bigger.

Why Am I Looking for Partners Now?

Because the problem is becoming bigger than one person.

The AI coding ecosystem is moving extremely quickly.

GitHub Copilot.

Claude Code.

Codex.

Cursor.

Gemini CLI.

OpenCode.

Cline.

Roo Code.

And whatever comes next.

The agents are getting better at writing and modifying software.

But the engineering problem around them is becoming more complicated.

Who defines the source of truth?

Who determines what an agent is allowed to change?

How do we prevent specification drift?

How do we preserve engineering decisions?

How do we maintain consistent context across different AI coding agents?

How do we verify generated artifacts?

How do we audit changes?

How do we make AI-assisted engineering reproducible?

How do we prevent vendor lock-in?

And eventually:

How do we safely give AI agents more autonomy without giving them unrestricted authority?

That's the territory I want NAEOS to explore.

The Current Architecture

The project isn't based on one giant prompt.

The architecture is layered.

At the center is NEIR.

Think of it as the canonical engineering model.

Conceptually:

                SPECIFICATION
                     │
                     ▼
                 PARSER
                     │
                     ▼
                NORMALIZER
                     │
                     ▼
                 RESOLVER
                     │
                     ▼
                    NEIR
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       POLICY     COMPILER    VALIDATOR
          │          │          │
          ▼          ▼          ▼
      GOVERNANCE   AI AGENTS   QUALITY
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
     Copilot       Codex       Claude
        │            │            │
        └────────────┼────────────┘
                     ▼
                  ARTIFACTS

The repository already contains AI adapters targeting multiple coding-agent environments, including GitHub Copilot, Claude Code, Cursor, Gemini CLI, Codex, and OpenCode.

The objective is not to build another proprietary AI agent.

It is to make the engineering layer agent-neutral.

The Part I Care About Most

There is another direction emerging inside the NAEOS thesis.

Governed AI execution.

An AI agent should be able to propose an action.

But proposing an action shouldn't automatically authorize it.

Conceptually:

AI Agent
   │
   │ proposes
   ▼
Policy Engine
   │
   │ decides
   ▼
Runtime
   │
   │ executes
   ▼
External System
   │
   │ changes state
   ▼
Independent Observation

This separation matters.

An agent can say:

"Deploy this."

The policy system determines whether that action is allowed.

The runtime executes the authorized action.

An independent observation layer determines what actually happened.

That leads to a more useful evidence chain:

Decision
   ↓
Execution
   ↓
Observation
   ↓
Evidence

Rather than simply:

Agent said it succeeded.

I believe this distinction will become increasingly important as AI agents move from generating code toward operating real systems.

What Already Exists

The public repository isn't empty.

The current codebase includes a declarative specification system, NEIR, compiler adapters, governance, policy evaluation, audit capabilities, MCP, marketplace infrastructure, profiles, templates, and a WASM-based plugin system.

There are also:

CLI tooling
documentation
tests
benchmarks
security controls
migration tooling
architecture patterns
pipeline caching
profiling
plugin hardening

The repository currently identifies v3.1.0 as the latest platform version and describes active development toward subsequent platform capabilities.

But don't mistake this for "finished."

It isn't.

That's exactly why I'm writing this.

Where I Need Partners

I'm specifically interested in engineers who want to take ownership of difficult technical areas.

1. AI Agent Runtime / Governance

If you're interested in:

agent authorization
policy engines
capability systems
execution boundaries
approval workflows
policy-as-code
agent identity
runtime enforcement

there is a lot to explore.

The interesting question isn't:

"How do we make an agent smarter?"

It's:

"How do we make an agent safely governable?"

2. Distributed Systems

NAEOS increasingly touches distributed-systems problems:

event-driven architecture
task execution
event sourcing
state transitions
distributed builds
retries
idempotency
replay
consistency
observability

If you enjoy designing systems where failures are expected rather than exceptional, this is your territory.

3. AI / Agent Infrastructure

If you're interested in:

LLM tooling
MCP
coding agents
context engineering
agent-to-agent communication
AI compilers
tool orchestration
model-independent infrastructure

there are several open problems.

Especially:

How do we create a common engineering layer without becoming dependent on a single AI vendor?

4. Go Backend Engineering

NAEOS is heavily implemented in Go.

If you have experience with:

Go
backend architecture
distributed systems
databases
APIs
concurrency
infrastructure

you can contribute directly to the core platform.

This isn't a documentation-only project.

There is real backend engineering work.

5. Security Engineering

This may become one of the most important areas.

We're dealing with systems where AI can potentially:

read
write
execute
deploy
communicate
delegate

Security questions therefore include:

capability boundaries
identity
authorization
provenance
untrusted input
replay protection
plugin isolation
supply-chain security
audit integrity
agent handoffs

If you think about security beyond authentication and authorization checkboxes, I'd like to talk.

6. Developer Experience

The architecture can be sophisticated.

The developer experience cannot be.

We need engineers who can answer:

"How can a developer understand NAEOS in 10 minutes?"

That includes:

CLI UX
documentation
examples
onboarding
templates
VS Code integration
AI-assisted development workflows
contributor experience

A powerful architecture nobody can understand is not a successful engineering platform.

I'm Not Looking for "Followers"

This distinction is important.

I'm not looking for people who simply want to:

⭐ Star the repository

That's appreciated.

But it isn't what I'm looking for.

I'm looking for people who will say:

"I disagree with this architecture."

And then open an issue explaining why.

People who will say:

"This policy model has a flaw."

And propose another model.

People who will say:

"This API is wrong."

And implement a better one.

People who will challenge assumptions.

That's the kind of open source community I want to build.

I Don't Need You to Agree With NAEOS

In fact, disagreement is valuable.

You might think the entire architecture is wrong.

Good.

Explain why.

Maybe NAEOS should be:

smaller
more modular
more runtime-oriented
more policy-oriented
less ambitious
more focused on AI agents
more focused on specification
integrated with existing platforms
completely redesigned

Those are useful conversations.

The project should be able to survive technical disagreement.

If it can't, the architecture isn't strong enough.

What I Can Offer

I'm building this as an open-source project under Apache 2.0.

What I can offer is:

ownership of a technical area
ability to influence architecture
public technical authorship
direct contribution to the roadmap
collaboration on specifications
opportunity to shape an emerging AI engineering discipline
potential long-term partnership for people who want to build this beyond open source

I'm not interested in creating a "volunteer task list."

I want people who can become technical owners of important parts of the system.

I'm Especially Interested in a Core Team

The project has reached the stage where a small group of serious engineers could dramatically change its trajectory.

The core team I'm looking for could eventually cover areas such as:

                    NAEOS
                      │
       ┌──────────────┼──────────────┐
       │              │              │
   Governance      Runtime        Compiler
       │              │              │
       ├──────────────┼──────────────┤
       │              │              │
    Security      Distributed       AI
       │           Systems          Infra
       │              │              │
       └──────────────┼──────────────┘
                      │
                  Ecosystem
                      │
              Plugins / Marketplace

The exact structure isn't fixed.

I'd rather design it with the people who join.

Who Should Not Join

This is probably just as important.

NAEOS is probably not for you if you want:

a finished product
a simple CRUD project
a wrapper around an LLM API
a project where architecture is already permanently decided
a place to collect GitHub stars
a passive contributor role with no ownership

There are easier projects.

I'm deliberately working on a difficult one.

Who I'm Looking For

If you're an engineer who is excited by questions like:

What should an AI agent be allowed to do?

How should that authority be represented?

How do we prove what happened?

How should agents hand off capabilities?

How do we preserve engineering context?

How do we compile one specification into multiple AI environments?

How should policy become executable?

How do we build vendor-neutral AI engineering infrastructure?

Then we may have something interesting to build together.

Start With the Repository

Don't send me a generic:

"I'm interested."

Do this instead.

Clone the repository.

Read the architecture.

Run the project.

Pick one component.

Find something you disagree with.

Open an issue.

Submit a PR.

Or tell me:

"I want to take ownership of this part."

That tells me much more than a résumé.

Repository:

https://github.com/NAEOS-foundation/naeos

Start with:

README.md
GETTING-STARTED.md
ARCHITECTURE-OVERVIEW.md
CONTRIBUTING.md
DEVELOPMENT_PLAN.md
ROADMAP.md
WHITEPAPER.md

Then explore:

constitution/
governance/
policy/
kernel/
internal/
pkg/
specification/
docs/

The repository itself is the best introduction to the project.

One Last Thing

I'm not trying to build another AI coding assistant.

There are already plenty.

I'm interested in a harder question:

What does software engineering look like when AI agents become first-class participants in the engineering system?

If the answer is simply:

"Give them more tokens and more permissions."

I think we're missing something.

If the answer involves:

Specification
      ↓
Architecture
      ↓
Policy
      ↓
AI Reasoning
      ↓
Verification
      ↓
Execution
      ↓
Observation
      ↓
Evidence

then I think there is a real engineering discipline to build.

That's what NAEOS is exploring.

The foundation exists.

Now I'm looking for the engineers who want to help decide what gets built on top of it.

If that's you, don't just tell me.

Open the repository.

Find the problem you want to own.

And let's build it.

Your AI Coding Agent Is Not Your Engineer — And That Should Terrify You

bayu priatno — Sun, 13 Sep 2026 14:26:08 +0000

Your AI Coding Agent Is Not Your Engineer — And That Should Terrify You

AI coding agents can write code.

They can read repositories.

They can modify dozens of files.

They can run tests.

They can open pull requests.

Some can even deploy to production.

So we started calling them software engineers.

I think that is a dangerous abstraction.

Not because AI agents are stupid.

But because they are becoming capable enough to create consequences that our current engineering controls were never designed to handle.

And this is where I think the AI engineering community is getting something fundamentally wrong.

The uncomfortable question

Imagine an AI agent receives this task:

"Upgrade the authentication system and deploy the changes."

The agent analyzes the repository.

It creates a plan.

It modifies the authentication middleware.

It updates dependencies.

It runs tests.

Everything passes.

Then it deploys.

Looks impressive.

But here is the question:

Who authorized the deployment?

Not:

Did the agent have permission to use the deployment tool?

A much harder question:

Was this specific external action actually authorized under the policy that was valid at the moment it happened?

Those are not the same thing.

Capability Is Not Authorization

This distinction sounds obvious in traditional software engineering.

A service account may have access to production.

That doesn't mean every operation performed using that credential is authorized.

A database user may have UPDATE permission.

That doesn't mean every update is legitimate.

Yet with AI agents, we often collapse these concepts.

We give an agent:

repository access
shell access
Git access
package managers
cloud credentials
deployment tools
APIs
browser access

And then we say:

"The agent has the tools it needs."

But having a capability is not the same as being authorized to exercise it in a particular context.

The distinction becomes critical when agents operate autonomously.

The Agent Can Be Correct and Still Be Wrong

This is the part I find most interesting.

Suppose the agent's reasoning is perfect.

It correctly understands the task.

It writes technically correct code.

All tests pass.

The implementation is architecturally sound.

And yet...

The action can still be unauthorized.

Why?

Because authorization is not a property of the model's reasoning.

Authorization is a property of the system.

This means we need to separate at least three things:

What the agent thinks
        ↓
What the policy allows
        ↓
What the runtime actually permits

These should not be the same component.

And the agent should not be allowed to decide all three.

"But We Have Human Approval"

Okay.

Let's make the scenario harder.

The agent creates a pull request.

A human reviews it.

The human clicks:

Approve

The system records:

approved = true

Is that enough?

I don't think so.

What exactly did the human approve?

Was it:

the diff?
the plan?
the deployment?
the dependency changes?
the external API calls?
the generated artifacts?
the intended side effects?

And what happens if the policy changes after approval?

Consider:

10:00
Agent proposes dependency X

10:02
Human approves

10:03
Policy changes
Dependency X is now prohibited

10:04
Agent executes installation

Does the approval at 10:02 magically override the policy at 10:03?

If yes, your policy is weaker than your approval workflow.

If no, then the system needs to re-evaluate authorization at execution time.

This is why I believe:

Approval is not authorization.

Approval can be an input into authorization.

It should not automatically become authorization.

Audit Logs Are Not Enough Either

Another common answer is:

"Don't worry. We have audit logs."

Great.

What do they contain?

Maybe:

agent started
agent modified files
agent opened PR
human approved
deployment completed

That sounds good.

Until you ask:

Can we prove what was actually authorized at the exact moment of execution?

A useful audit system needs to answer questions like:

Who initiated the action?

Which agent identity was involved?

Which capability was requested?

Which capability was granted?

Which policy version was evaluated?

Which approval was referenced?

What payload was authorized?

What external side effect was dispatched?

Which runtime actually executed it?

What evidence proves that the runtime enforced the decision?

That is a very different thing from:

"We have logs."

An audit trail should not merely describe what happened.

It should help establish why the system was allowed to let it happen.

Agent Memory Is Not Evidence

This creates another uncomfortable distinction.

An AI agent might say:

"I already checked that."

Maybe it did.

Maybe it didn't.

Maybe the context was truncated.

Maybe the model forgot.

Maybe another agent performed the check.

Maybe the policy changed afterward.

Maybe the tool returned a manipulated result.

The model's memory is not a durable source of truth.

This gives us a fundamental principle:

What an agent remembers is not the same as what a system can prove.

And I think this distinction is going to become increasingly important as we move from single-agent coding assistants toward multi-agent engineering systems.

What Happens When Agents Disagree?

Now imagine two independent AI systems inspect the same change.

Agent A:

"This change is safe."

Agent B:

"This introduces a security risk."

Which one wins?

Today, the typical answer is:

"Ask a better model."

I'm not convinced.

Disagreement itself can be useful evidence.

Instead of hiding disagreement, an engineering system could surface:

Agent A: APPROVE
Agent B: REJECT

Confidence divergence: HIGH

Reason:
Agent B identified an authorization-path modification
that Agent A did not evaluate.

The goal isn't to blindly vote between models.

The goal is to make uncertainty observable.

That is a fundamentally different engineering philosophy.

The Bigger Problem: AI Agents Cross Trust Boundaries

An AI coding agent isn't just generating text.

It can cross boundaries.

Human
  ↓
AI Agent
  ↓
Repository
  ↓
Tool
  ↓
Cloud
  ↓
Production
  ↓
External users

Every transition introduces a trust question.

What did the upstream component request?

What was actually authorized?

What information was trusted?

What information was untrusted?

Can the downstream component distinguish data from instructions?

Can the request be replayed?

Can permissions be widened during the handoff?

Can a malicious tool response influence the next agent?

These aren't traditional prompt-engineering problems.

They are systems engineering problems.

This Is Why I Don't Think "Better Prompts" Solve AI Engineering

Prompt engineering is useful.

Better models are useful.

Better coding agents are useful.

But eventually you hit a boundary where:

The problem is no longer what the model can reason about.

The problem becomes:

What the system is allowed to do.

That requires things like:

policy
authorization
capability control
identity
provenance
auditability
verification
deterministic enforcement
runtime boundaries
explicit approvals
replay protection
versioned contracts

In other words:

engineering infrastructure for AI agents.

The Controversial Idea

This is where NAEOS comes in.

NAEOS — Nusantara AI Engineering Operating System — is based on a simple thesis:

AI coding agents should not be treated as autonomous engineers. They should operate inside an engineering system that constrains, verifies, observes, and governs their actions.

That sounds restrictive.

It is.

That's the point.

We don't need to make agents less capable.

We need to make the system around them more capable.

The agent should be able to reason.

But the system should decide what is authorized.

The agent can propose.

The system can verify.

The human can approve.

The runtime can enforce.

The audit system can preserve evidence.

Those responsibilities should not collapse into a single AI model.

NAEOS Is Not Another Coding Agent

This is another distinction worth making.

NAEOS isn't trying to compete with:

Claude Code
OpenAI Codex
GitHub Copilot
Cursor
Gemini CLI
Cline
Roo Code
Windsurf
other coding agents

The premise is almost the opposite.

Use whichever agent you want.

The engineering system should sit around the agent.

Think of it as an architectural layer:

┌─────────────────────────────┐
│          Human              │
├─────────────────────────────┤
│ Governance & Approval       │
├─────────────────────────────┤
│ Policy & Authorization      │
├─────────────────────────────┤
│ Verification & Audit        │
├─────────────────────────────┤
│ NAEOS Runtime / Control     │
├─────────────────────────────┤
│ AI Coding Agent             │
├─────────────────────────────┤
│ Tools / APIs / Infrastructure│
└─────────────────────────────┘

The agent is powerful.

But it isn't sovereign.

"Isn't This Just Enterprise Overengineering?"

Maybe.

If your AI agent only generates a Python function on your laptop, you probably don't need this.

If an agent can:

modify production infrastructure
change authentication
access customer data
trigger financial operations
send external communications
deploy software
modify security policies
operate other agents

then the equation changes.

The larger the change surface and blast radius, the stronger the verification and authorization requirements should become.

Not simply:

small diff = low risk
large diff = high risk

A two-line change to an authentication policy can be more dangerous than a 500-line refactor.

Risk should depend on:

change surface
×
blast radius
×
change characteristics

Not just lines of code.

The Future Problem Nobody Wants to Talk About

We're going to build systems where one AI agent delegates to another.

Something like:

Planner Agent
     ↓
Coding Agent
     ↓
Testing Agent
     ↓
Security Agent
     ↓
Deployment Agent
     ↓
Production

Now ask:

What exactly is transferred between them?

A message?

A plan?

A capability?

A permission?

A claim?

A tool result?

An instruction?

This is where protocol-neutral handoffs become important.

A handoff should have explicit semantics around things like:

initiator
requested capability
authorized capability set
payload contract
untrusted inputs
allowed downstream actions
policy version
contract version
canonicalization version
provenance
expiry
replay state

Otherwise we're effectively saying:

"Here is some text another AI generated. Please trust it."

That doesn't sound like engineering.

It sounds like distributed prompt passing.

Maybe We Are Building the Wrong Layer First

The AI industry is obsessed with making agents more autonomous.

More tools.

More memory.

More context.

More actions.

More autonomy.

But autonomy without control is not maturity.

It's simply a larger blast radius.

I think the next generation of AI engineering infrastructure will care less about:

"How do we make the agent do more?"

and more about:

"How do we prove what the agent was allowed to do?"

That is a much harder problem.

And probably a much more important one.

The Question I Want Engineers to Argue About

I don't want everyone to agree with NAEOS.

Actually, I would prefer the opposite.

Tell me where this model is wrong.

Should an AI agent ever be allowed to authorize its own actions?

Is human approval sufficient?

Should authorization be evaluated only once, or again immediately before execution?

Can an audit trail prove anything meaningful without binding policy, identity, payload, and execution evidence together?

Should disagreement between independent AI systems be treated as a failure — or as an observability signal?

And perhaps the biggest question:

At what point does an AI coding agent stop being a coding assistant and become a production system that requires the same engineering controls as any other distributed system?

I don't think we've answered that yet.

But we're already deploying the agents.

That's what worries me.

NAEOS

NAEOS is an open-source attempt to explore this problem as an AI Engineering Operating System rather than another AI coding tool.

The goal isn't to make AI less autonomous.

The goal is to make autonomy governable, verifiable, auditable, and enforceable.

Because eventually, the most important question about an AI system won't be:

"How intelligent is the agent?"

It will be:

"Can we prove why it was allowed to do what it did?"

That is the conversation I think AI engineering needs to have next.

NEIR: The Intermediate Representation at the Center of NAEOS

bayu priatno — Thu, 10 Sep 2026 16:14:32 +0000

In the previous article, we looked at the architecture behind NAEOS and the idea of treating software engineering as a pipeline rather than a collection of disconnected tools.

At the center of that pipeline is a concept that deserves a deeper look:

NEIR — NAEOS Engineering Intermediate Representation.

If NAEOS is an engineering operating system, NEIR is one of its most important internal abstractions.

It sits between human-readable engineering specifications and the systems that consume them.

Specification
      │
      ▼
   Parsing
      │
      ▼
 Normalization
      │
      ▼
 Resolution
      │
      ▼
     NEIR
      │
 ┌────┼───────────────┐
 ▼    ▼               ▼
AI   Validation    Generation

The purpose is not simply to create another data structure.

The purpose is to create a shared semantic model of an engineering system.

The Problem With Direct Specification-to-Code Generation

A simple generator can work like this:

YAML
 │
 ▼
Generator
 │
 ▼
Source Code

This works for small projects.

But software engineering becomes much more complicated when the specification describes:

multiple modules
services
APIs
databases
infrastructure
security requirements
deployment
testing
AI agents
architectural constraints

Now imagine adding multiple consumers:

Specification
 ├──→ Code Generator
 ├──→ Documentation Generator
 ├──→ AI Agent
 ├──→ Validator
 ├──→ Infrastructure Generator
 └──→ Architecture Analyzer

Every consumer has to understand the specification independently.

That creates a problem.

Each subsystem develops its own interpretation of the system.

Eventually:

Specification
      │
      ├── Generator interpretation
      ├── Validator interpretation
      ├── AI interpretation
      ├── Documentation interpretation
      └── Infrastructure interpretation

These interpretations can diverge.

This is the same class of problem compiler architectures have addressed through intermediate representations.

The Compiler Analogy

A traditional compiler does not need every backend to understand every source language.

Instead, source code is transformed into an intermediate representation.

Source Code
    │
    ▼
   AST
    │
    ▼
Intermediate Representation
    │
 ┌──┼──────┐
 ▼  ▼      ▼
x86 ARM   WASM

The IR creates a stable boundary.

NAEOS applies a similar architectural idea to engineering systems.

Engineering Specification
          │
          ▼
        NEIR
          │
 ┌────────┼────────┐
 ▼        ▼        ▼
Code     AI      Governance
Gen.     Context   Validation

The difference is that NEIR is not a representation of a programming language.

It is a representation of an engineering system.

What Does NEIR Represent?

The NAEOS repository describes NEIR around engineering concepts such as:

Project
Architecture
Domain
Module
Component
Service
API
Storage
Infrastructure
Security
AI
Documentation
Deployment
Testing
Metadata

That distinction is important.

Consider this:

func CreatePayment() error {
    // implementation
}

The function itself is implementation detail.

But the engineering model might need to know:

Payment Service
 ├── belongs to Payments Domain
 ├── exposes POST /payments
 ├── depends on Identity
 ├── persists data in PostgreSQL
 ├── requires authentication
 └── must satisfy architectural policies

NEIR represents the latter.

The implementation can change.

The engineering intent remains.

Engineering Intent vs Implementation

This distinction is fundamental.

Consider:

Intent
──────

There must be a Payment service.

The service exposes an HTTP API.

The service requires authentication.

The service uses PostgreSQL.

That intent can produce multiple implementations.

                 Payment Service
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
       Go          TypeScript       Rust
        │              │              │
        ▼              ▼              ▼
 Implementation  Implementation  Implementation

The implementation language is not the engineering identity of the service.

This separation gives NAEOS a much more useful abstraction boundary.

NEIR as a Semantic Boundary

A useful way to think about NEIR is:

NEIR separates what the engineering system means from how a particular tool implements it.

                 Engineering Intent
                         │
                         ▼
                       NEIR
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
    Generator         Validator         AI Compiler
       │                 │                 │
       ▼                 ▼                 ▼
    Source Code       Policy Result      AI Context

This prevents downstream components from becoming tightly coupled to the original specification format.

Why Not Just Use the AST?

An obvious question is:

Why not simply use the parser's AST?

Because an AST answers a different question.

An AST primarily represents the syntactic structure of the input.

For example:

services:
  - name: payments
    port: 8080

The AST tells us how that document was structured.

But the engineering system needs to understand:

Service
  name = payments
  protocol = HTTP
  port = 8080
  dependencies = [...]
  policies = [...]
  deployment = [...]

The difference is:

AST
↓
What did the document say?

NEIR
↓
What does the engineering system mean?

That semantic distinction is what makes an IR useful.

From Specification to NEIR

The transformation can be viewed as several stages.

             Raw Specification
                     │
                     ▼
                  Parser
                     │
                     ▼
                    AST
                     │
                     ▼
               Normalization
                     │
                     ▼
                 Resolution
                     │
                     ▼
                    NEIR

Each stage has a different responsibility.

Parser

Understand syntax.

Normalizer

Create canonical representations.

Resolver

Resolve relationships and references.

NEIR

Represent the resulting engineering system.

This separation makes the pipeline easier to reason about and test.

Relationships Matter

One of the biggest advantages of an engineering IR is that relationships become explicit.

For example:

Identity
   ▲
   │ dependency
   │
Payments
   │
   ├── exposes → Payment API
   │
   ├── stores → Payment Database
   │
   └── deployed-on → Kubernetes

A flat configuration file may contain all of this information.

But NEIR can represent these relationships explicitly.

This makes graph-oriented operations possible.

For example:

Find all services depending on Identity.

Find all APIs exposed by Payments.

Find all components using PostgreSQL.

Find all resources violating a policy.

Find all artifacts generated from a specific specification node.

These are engineering queries, not text-processing operations.

NEIR as a Graph

Conceptually, NEIR can be understood as an engineering graph.

                 ┌─────────────┐
                 │   Project   │
                 └──────┬──────┘
                        │
                        ▼
                ┌───────────────┐
                │ Architecture  │
                └───────┬───────┘
                        │
             ┌──────────┴──────────┐
             ▼                     ▼
        ┌─────────┐           ┌─────────┐
        │ Identity│           │Payments │
        └────┬────┘           └────┬────┘
             │                     │
             │              ┌──────┼──────┐
             │              ▼      ▼      ▼
             │             API   Storage Service
             │
             └──────── dependency ────────►

Once engineering information is represented as a graph, many capabilities become possible.

Validation Becomes Graph Reasoning

Suppose the architecture defines:

Domain
  ↓
Application
  ↓
Infrastructure

and prohibits:

Domain
  ↓
Infrastructure

The validator can inspect the graph.

Domain ────────────X──────────> Infrastructure

Instead of relying on a human reviewer to notice the violation, the rule can become executable.

Conceptually:

NEIR
 │
 ▼
Policy Engine
 │
 ▼
Graph Evaluation
 │
 ├── valid
 └── violation

This is one of the strongest reasons to maintain a semantic engineering model.

Generation Becomes Model Consumption

Generators can also consume NEIR.

For example:

NEIR
 │
 ├── Service
 │     ├── API
 │     ├── Dependencies
 │     └── Storage
 │
 ▼
Go Generator
 │
 ▼
Go Project

Another generator can consume the same model:

NEIR
 │
 ▼
TypeScript Generator
 │
 ▼
TypeScript Project

The engineering model remains the same.

Only the target changes.

AI Context Becomes Model-Derived

The same principle applies to AI.

Instead of manually maintaining a massive collection of instructions:

README
CLAUDE.md
Cursor Rules
Copilot Instructions
Developer Notes
Architecture Docs

NAEOS can derive AI context from the engineering model.

Conceptually:

NEIR
 │
 ▼
AI Context Compiler
 │
 ├──→ Claude Code
 ├──→ Cursor
 ├──→ GitHub Copilot
 ├──→ Codex
 ├──→ Gemini CLI
 └──→ Other Agents

The repository currently contains adapters for several AI coding environments, making this model particularly relevant to the NAEOS architecture. (github.com)

The important idea is not the individual adapter.

It is the common source.

                NEIR
                 │
                 ▼
          AI Context Model
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
    Agent A   Agent B   Agent C

Different agents can consume the same engineering truth.

One Model, Multiple Outputs

This gives NAEOS an important property:

                         NEIR
                          │
       ┌──────────────────┼──────────────────┐
       │                  │                  │
       ▼                  ▼                  ▼
    Source Code      Documentation       AI Context
       │                  │                  │
       ▼                  ▼                  ▼
    Artifacts          Artifacts          Instructions

The system no longer needs every output to be manually synchronized.

They can be derived from the same model.

Traceability

Another important consequence is traceability.

Imagine a generated file:

internal/payment/service.go

The system should ideally be able to answer:

Where did this artifact come from?

Which specification defined it?

Which NEIR node generated it?

Which policies were evaluated?

Which generator produced it?

Which version of the engineering model was used?

This creates a chain:

Specification
     │
     ▼
    NEIR
     │
     ▼
Generation Plan
     │
     ▼
Artifact

That chain becomes valuable for debugging, auditing, governance, and reproducibility.

Reproducibility

A shared intermediate representation also creates a better foundation for reproducibility.

Instead of:

Prompt
  ↓
AI
  ↓
Different result tomorrow

the target becomes:

Specification
     +
Schema
     +
NEIR
     +
Policies
     +
Generator Version
     ↓
Engineering Artifact

AI can still participate.

But AI is no longer required to reconstruct the entire engineering context from scratch every time.

The Trade-Off

NEIR is not free.

Introducing an intermediate representation adds:

schema complexity
transformation logic
versioning concerns
migration requirements
additional validation
more runtime components

For a small project, this may be unnecessary.

If you only need:

config → template → code

a conventional generator is probably enough.

The value appears when the engineering system becomes complex.

When there are many consumers of the same engineering information, the intermediate representation becomes an architectural asset.

NEIR Versioning

An engineering IR also introduces a critical question:

What happens when the model evolves?

Suppose version 1 contains:

Service
API
Database

and version 2 adds:

Service
API
Database
Event
SecurityPolicy
Deployment

Consumers need compatibility strategies.

This makes schema versioning important.

A mature IR needs to consider:

Backward Compatibility
Forward Compatibility
Migration
Validation
Deprecation
Version Negotiation

This is not unique to NAEOS.

It is a fundamental property of any long-lived intermediate representation.

The Architectural Payoff

The real benefit of NEIR is not that it makes YAML easier to parse.

It creates a stable boundary between engineering intent and engineering execution.

                 HUMAN INTENT
                      │
                      ▼
                Specification
                      │
                      ▼
                     NEIR
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
   Governance       AI             Build
       │              │              │
       ▼              ▼              ▼
    Policies       Context        Artifacts

That boundary allows NAEOS to evolve without forcing every subsystem to understand every representation.

NEIR and the Engineering Operating System

This brings us back to the larger NAEOS architecture.

An operating system provides abstractions.

Applications do not need to directly understand every hardware detail.

Similarly, an engineering operating system should provide abstractions that allow engineering tools to work against a common system model.

In this analogy:

Operating System
      │
      ├── Process Model
      ├── Resource Model
      ├── Security Model
      └── System APIs

NAEOS moves toward:

Engineering Operating System
      │
      ├── Engineering Model
      ├── Policy Model
      ├── Execution Model
      ├── Artifact Model
      └── AI Context Model

NEIR sits near the center of this architecture.

The Core Idea

The most important idea can be summarized like this:

Code is an artifact. The engineering system is the model that produces and governs those artifacts.

That changes the role of AI as well.

AI does not need to become the source of truth.

AI can become one of the execution engines operating against the source of truth.

                     Engineering Model
                            │
                ┌───────────┼───────────┐
                ▼           ▼           ▼
             Humans        AI        Automation
                │           │           │
                └───────────┼───────────┘
                            ▼
                        Artifacts

That is the architectural direction NAEOS is exploring.

Conclusion

NEIR is more than an internal data structure.

It is an architectural boundary.

It allows NAEOS to connect:

specifications
architecture
governance
validation
scheduling
generation
AI agents
documentation
deployment
testing
artifacts

through a shared engineering representation.

The resulting pipeline looks like:

Intent
  ↓
Specification
  ↓
Parsing
  ↓
Normalization
  ↓
Resolution
  ↓
NEIR
  ↓
Validation + Governance
  ↓
Scheduling
  ↓
Generation / AI
  ↓
Artifacts

The key question is no longer:

"Which AI coding tool should we use?"

It becomes:

"What engineering model should every coding tool operate against?"

That is the problem NEIR is designed to address.

Next: Part 3

From Specification to Software: Inside the NAEOS Compilation Pipeline

In the next article, we will move from the NEIR model into execution and examine how NAEOS transforms an engineering model into a validated and schedulable execution plan.

NEIR: The Intermediate Representation at the Center of NAEOS

bayu priatno — Thu, 10 Sep 2026 15:58:33 +0000

Inside NAEOS: Building an Engineering Operating System Around a Single Source of Truth

bayu priatno — Wed, 09 Sep 2026 20:15:44 +0000

Most AI coding tools start with code.

NAEOS starts one layer earlier: the engineering specification.

The idea behind NAEOS is simple:

Specify the system once. Build, validate, and evolve it through a consistent engineering pipeline.

But implementing that idea requires more than a project generator.

It requires an architecture that can understand engineering intent, transform it into a machine-readable model, validate it against rules, produce execution plans, generate artifacts, and keep AI agents aligned with the same system model.

This article explains the architecture behind NAEOS and why it is designed more like an engineering operating system than a traditional code generator.

The Problem With Code-First AI Engineering

Modern AI coding agents are remarkably capable.

Give an agent a prompt such as:

Build a payment service with authentication,
PostgreSQL, REST APIs, and a background worker.

It can produce a significant amount of code.

But there is a deeper problem.

Where does the engineering intent live after the code has been generated?

Consider a system with:

20 modules
15 services
40 APIs
multiple databases
infrastructure dependencies
security requirements
architectural constraints
multiple AI agents

If the system is represented primarily through source code and prompts, the engineering model becomes fragmented.

You may have:

Source Code
Documentation
Architecture Diagrams
Configuration
AI Instructions
CI/CD Configuration
Infrastructure
Developer Knowledge

Each contains part of the truth.

The result is engineering drift.

A Different Model

NAEOS introduces a different abstraction:

                 Engineering Specification
                           │
                           ▼
                     NAEOS Pipeline
                           │
              ┌────────────┴────────────┐
              │                         │
              ▼                         ▼
            NEIR                    Governance
              │                         │
              └────────────┬────────────┘
                           ▼
                     Execution Plan
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
          Generator      AI Compiler    Context
             │             │             │
             └─────────────┴─────────────┘
                           │
                           ▼
                       Artifacts

The specification becomes the starting point.

Code, AI instructions, documentation, and other artifacts become outputs derived from the engineering model.

This is the fundamental architectural decision behind NAEOS.

The NAEOS Pipeline

At the core of NAEOS is a staged engineering pipeline:

Specification
      │
      ▼
    Parser
      │
      ▼
  Normalizer
      │
      ▼
   Resolver
      │
      ▼
     NEIR
      │
      ▼
   Validator
      │
      ▼
   Scheduler
      │
      ▼
   Generators
      │
      ├───────────────┐
      ▼               ▼
   Artifacts       AI Context

The current implementation exposes these responsibilities as separate components in the repository, including specification parsing, normalization, resolution, NEIR construction, validation, scheduling, generation, governance, and AI compilation.

The important property is separation of concerns.

A parser should not decide architectural policy.

A generator should not redefine the system model.

An AI adapter should not become the source of truth.

Each stage has a specific responsibility.

1. Specification

Everything starts with a declarative specification.

For example:

project: payments

architecture:
  pattern: hexagonal

modules:
  - name: identity

  - name: payments
    dependencies:
      - identity

services:
  - name: api
    kind: http
    port: 8080

generation:
  languages:
    - go
    - typescript

The specification describes what the system is supposed to be.

It does not need to contain every implementation detail.

The goal is to establish a structured engineering intent that downstream components can understand.

NAEOS Specification Language v2 also supports features such as variable interpolation, environment variables, references, multi-file composition, functions, conditionals, and schema versioning.

2. Parser

The parser converts the external representation into an internal structure.

Conceptually:

YAML / JSON / HCL
        │
        ▼
      Parser
        │
        ▼
   Structured Data

This layer should answer:

Is this specification syntactically understandable?

It should not answer:

Is this architecture acceptable?

That distinction becomes important as the system grows.

3. Normalization

Different specifications can express the same concept in different ways.

Normalization creates a consistent representation.

Input A ─┐
         ├──> Normalizer ──> Canonical Model
Input B ─┘

For example, aliases, defaults, optional fields, and equivalent representations can be normalized before deeper processing.

This makes downstream processing significantly more predictable.

4. Resolution

Specifications frequently contain relationships.

For example:

modules:
  - name: payments
    dependencies:
      - identity

The resolver must understand what identity refers to.

The same principle applies to:

references
dependencies
profiles
templates
configuration
imported specifications

Conceptually:

Normalized Specification
          │
          ▼
       Resolver
          │
          ▼
Resolved Engineering Model

5. NEIR

This is where NAEOS becomes particularly interesting.

NEIR — NAEOS Engineering Intermediate Representation — is the central engineering model.

Instead of allowing every subsystem to interpret the original specification independently, NAEOS creates a shared intermediate representation.

                Specification
                      │
                      ▼
              ┌──────────────┐
              │     NEIR     │
              └──────────────┘
                 │    │    │
        ┌────────┘    │    └────────┐
        ▼             ▼             ▼
    Generator      Validator     AI Compiler
        │             │             │
        ▼             ▼             ▼
      Code          Policy       Instructions

The repository describes NEIR as representing the broader engineering system, including project, architecture, domain, modules, components, services, APIs, storage, infrastructure, security, AI, documentation, deployment, testing, and metadata.

This gives NAEOS a common semantic layer.

Why an Intermediate Representation Matters

Compiler engineers have used intermediate representations for decades.

A compiler does not normally translate every source language directly into every machine architecture.

Instead:

Source
  │
  ▼
AST
  │
  ▼
Intermediate Representation
  │
  ▼
Optimization
  │
  ▼
Target

NAEOS applies a similar idea to software engineering.

Instead of:

Specification → Generator
Specification → AI Agent
Specification → Documentation
Specification → Validation

we can have:

                    Specification
                          │
                          ▼
                         NEIR
                 ┌────────┼────────┐
                 ▼        ▼        ▼
             Generator Validator AI Compiler
                 │        │        │
                 ▼        ▼        ▼
               Code     Policy   AI Context

The intermediate representation becomes the common language between engineering capabilities.

6. Validation

Once the system has been represented as NEIR, NAEOS can reason about it.

For example:

Module A
   │
   └── depends on → Module B

The validator can detect architectural problems such as:

circular dependencies
invalid module boundaries
conflicting ports
invalid references
policy violations

This is fundamentally different from asking an AI model:

"Does this architecture look correct?"

The validator can enforce deterministic rules.

7. Scheduling

Engineering operations often form a dependency graph.

For example:

Database
   │
   ▼
Domain
   │
   ▼
Application
   │
   ▼
API
   │
   ▼
Tests

NAEOS can represent execution as a DAG:

Task A ─────┐
            ▼
          Task C
            ▲
Task B ─────┘

This allows independent operations to execute independently while respecting dependencies.

The repository describes the scheduler as DAG-based task scheduling.

8. Generation

Once the system has passed validation, generators can produce artifacts.

The important distinction is:

The generator consumes the engineering model.

It does not redefine the engineering model.

Conceptually:

                 NEIR
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
      Go      TypeScript   Python
       │          │          │
       ▼          ▼          ▼
    Artifact   Artifact   Artifact

The current NAEOS repository lists generators for multiple languages, including Go, TypeScript, Python, Java, and Rust.

9. AI Compilation

This is another important architectural boundary.

NAEOS does not have to replace AI coding agents.

Instead, it can compile engineering context into instructions understood by different AI development environments.

The architecture becomes:

                    NEIR
                      │
                      ▼
                AI Compiler
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
   Claude Code     Cursor       Copilot
        │             │             │
        ▼             ▼             ▼
    Instructions   Rules        Instructions

The repository currently includes adapters for tools such as GitHub Copilot, Claude Code, Cursor, Gemini CLI, Codex, OpenCode, and Windsurf.

This leads to an important architectural principle:

AI agents should consume the engineering model rather than become the engineering model.

Prompt Is Not Policy

This distinction becomes critical when AI agents can modify real systems.

A prompt might say:

Do not modify the payment database.

But a prompt is not a reliable security boundary.

A stronger architecture is:

AI Agent
   │
   │ request
   ▼
NAEOS Control Layer
   │
   ├── Policy
   ├── Validation
   ├── Authorization
   └── Audit
   │
   ▼
Allowed Action

The agent can be highly capable without being given unrestricted authority.

This is one of the reasons an engineering operating system needs a control layer rather than simply an AI interface.

Governance as an Engineering Layer

NAEOS also treats governance as part of the engineering pipeline.

Conceptually:

Specification
      │
      ▼
     NEIR
      │
      ▼
   Policies
      │
      ▼
 Validation
      │
      ▼
 Artifact Review
      │
      ▼
   Approved Output

The repository currently includes policy evaluation, artifact review, and audit-trail capabilities.

This changes governance from documentation into something closer to an executable engineering mechanism.

Instead of:

"Our architecture follows these rules."

the system can move toward:

"These rules are machine-readable and evaluated during engineering execution."

The Kernel

Underneath these capabilities is the NAEOS kernel.

The repository describes the kernel as providing foundational runtime services such as:

service registry
event bus
telemetry
lifecycle management

This gives the higher-level pipeline a common runtime foundation.

The resulting architecture can be viewed as:

┌───────────────────────────────────────────┐
│              NAEOS Applications            │
│                                           │
│ CLI │ AI │ Generator │ Governance │ MCP   │
├───────────────────────────────────────────┤
│              Engineering Pipeline          │
│                                           │
│ Parse → Normalize → Resolve → NEIR        │
│             → Validate → Schedule         │
├───────────────────────────────────────────┤
│                   Kernel                   │
│                                           │
│ Registry │ Events │ Telemetry │ Lifecycle │
├───────────────────────────────────────────┤
│            Runtime / Platform              │
└───────────────────────────────────────────┘

Extensibility

An engineering operating system cannot be closed around a single implementation strategy.

NAEOS therefore exposes extensibility through plugins, profiles, templates, marketplace components, and other adapters.

The repository includes a plugin SDK with a WASM runtime, profile and plugin marketplace capabilities, and multiple built-in industry profiles.

The architectural goal is:

                  NAEOS Core
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
    Plugins         Profiles      Adapters
       │              │              │
       ▼              ▼              ▼
      WASM       Domain Context    AI Tools

The core remains stable while capabilities can evolve around it.

The Full Architecture

Putting the pieces together:

                         Developer
                             │
                             ▼
                    Engineering Spec
                             │
                             ▼
                         Parser
                             │
                             ▼
                       Normalizer
                             │
                             ▼
                         Resolver
                             │
                             ▼
                           NEIR
                             │
            ┌────────────────┼────────────────┐
            │                │                │
            ▼                ▼                ▼
        Governance       Validation       Context
            │                │                │
            └────────────────┼────────────────┘
                             ▼
                         Scheduler
                             │
               ┌─────────────┼─────────────┐
               │             │             │
               ▼             ▼             ▼
           Generator     AI Compiler     Plugins
               │             │             │
               ▼             ▼             ▼
             Code        AI Context     Extensions
               │             │             │
               └─────────────┼─────────────┘
                             ▼
                         Artifacts
                             │
                             ▼
                       Verification
                             │
                             ▼
                       Engineering
                         System

This is the architectural idea behind NAEOS.

Not:

Prompt → Code

But:

Intent
  ↓
Specification
  ↓
Engineering Model
  ↓
Governance
  ↓
Execution
  ↓
Artifacts
  ↓
Verification

Why This Architecture Matters

AI has dramatically reduced the cost of generating code.

But code generation is only one part of software engineering.

Large engineering systems still require:

architecture
constraints
dependency management
validation
security
governance
reproducibility
documentation
testing
traceability
controlled execution

The challenge is therefore shifting.

The question is no longer:

"Can AI write the code?"

The more important question becomes:

"Can we give AI enough capability to build software without losing control of the engineering system?"

NAEOS explores one possible answer.

Create a machine-readable engineering model.

Make it the common source of truth.

Put deterministic validation and governance around it.

Then allow generators, AI agents, plugins, and other tools to operate against that model.

The Core Principle

The architecture can ultimately be summarized in one sentence:

AI should accelerate engineering execution, but the engineering system should remain the authority.

That distinction is at the center of NAEOS.

The project is open source and actively evolving, with the current repository documenting the implementation, architecture, specifications, CLI, governance, AI integration, plugin system, and runtime components.

If this direction is interesting, the next question is much more technical:

How exactly does NEIR work?

That will be the subject of the next article.

Part 2 — NEIR: The Intermediate Representation at the Center of NAEOS

We will go inside the NEIR model, examine why an engineering IR is necessary, and explore how one representation can become the foundation for validation, generation, governance, and AI context.

NAEOS Founder Journal-The Foundation Is Being Built. Now We Need Builders.

bayu priatno — Sun, 06 Sep 2026 11:30:36 +0000

For the last phase of building NAEOS, I have been asking myself a simple question:

What happens when software engineering becomes specification-driven, AI-assisted, and increasingly autonomous?

I don't think the answer is another AI coding assistant.

I think we need an engineering system.

That is what I am building with NAEOS.

What NAEOS Actually Is

NAEOS stands for Nusantara Engineering & Architecture Operating System.

The core idea is:

Specify Once. Build Anywhere.

Instead of starting with code, NAEOS starts with a structured specification.

That specification becomes the source of truth for the engineering system.

From there, NAEOS can parse, normalize, resolve, validate, model, schedule, compile, generate, test, document, and manage engineering artifacts.

The project already has a working foundation for this approach.

The repository currently includes the NAEOS specification pipeline, NEIR engineering model, AI compiler, MCP integration, governance, marketplace, plugin infrastructure, testing, documentation generation, security, knowledge components, database integrations, event sourcing, distributed execution, pipeline caching, and more.

This is no longer just a concept.

The foundation exists.

Now the question becomes:

Who should build the next layer with me?

The Problem

Software engineering has become increasingly fragmented.

A modern project can involve:

multiple programming languages
multiple frameworks
multiple infrastructure providers
multiple deployment environments
multiple engineering standards
multiple AI coding agents
multiple documentation systems
multiple security requirements

And now we are adding another layer:

AI agents.

GitHub Copilot, Claude Code, Cursor, Gemini CLI, Codex, OpenCode and other systems can increasingly participate in software development.

But each tool has its own context format, instructions, capabilities, and workflow.

The engineering organization still has to provide:

Architecture

Standards

Policies

Context

Knowledge

Validation

Governance

Traceability

NAEOS is designed to become that layer.

The Core Thesis

NAEOS is built around a simple thesis:

Software should be derived from a structured engineering specification rather than assembled independently across disconnected tools.

The specification becomes the source of truth.

NAEOS transforms that specification into an internal engineering model called NEIR — NAEOS Engineering Intermediate Representation.

NEIR represents the system across architecture, domains, modules, services, APIs, storage, infrastructure, security, AI, documentation, deployment, testing, and metadata.

Conceptually:

                    Engineering Specification
                              │
                              ▼
                    ┌───────────────────┐
                    │   NAEOS Parser    │
                    └─────────┬─────────┘
                              │
                              ▼
                    ┌───────────────────┐
                    │ Normalizer /      │
                    │ Resolver          │
                    └─────────┬─────────┘
                              │
                              ▼
                    ┌───────────────────┐
                    │       NEIR        │
                    │ Engineering Model │
                    └─────────┬─────────┘
                              │
             ┌────────────────┼────────────────┐
             ▼                ▼                ▼
        Validation        Governance       AI Compiler
             │                │                │
             └────────────────┼────────────────┘
                              ▼
                     Engineering Artifacts
                              │
          ┌───────────────┬───┴────┬──────────────┐
          ▼               ▼        ▼              ▼
         Code           Docs      Tests       AI Context

This architecture is what makes NAEOS fundamentally different from a conventional project generator.

The AI Layer

One of the most important parts of NAEOS is the relationship between the engineering model and AI agents.

NAEOS can compile engineering context into instructions for multiple AI development environments.

The current repository documents adapters for:

GitHub Copilot
Claude Code
Cursor
Gemini CLI
Codex
OpenCode

It also includes MCP integration and LLM-optimized context bundles.

The goal is not to replace these tools.

It is to make them operate from the same engineering source of truth.

That distinction matters.

NAEOS is not trying to win the AI coding assistant war.

It is trying to build the layer above the assistants.

From Coding Assistant to Engineering Runtime

This is where I believe the bigger opportunity exists.

Today:

Developer
    │
    ▼
AI Coding Agent
    │
    ▼
Code

The future could look more like:

                 Engineering Specification
                           │
                           ▼
                    NAEOS Engineering
                       Runtime
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
    Governance          Knowledge            Policy
        │                  │                  │
        └──────────────────┼──────────────────┘
                           ▼
                    AI Agent Layer
                           │
                           ▼
                     Engineering
                       Actions
                           │
                           ▼
                  Validated Artifacts

The AI agent becomes a participant inside the engineering system.

Not the system itself.

What Has Already Been Built

This is an important distinction for anyone considering joining NAEOS.

This is not a pitch deck looking for someone to build the first prototype.

The repository already contains a substantial engineering foundation.

Among the implemented areas are:

Specification Engine

NAEOS Specification Language v2 supports variables, environment resolution, references, includes, functions, conditionals, and schema versioning.

NEIR

A central engineering representation connecting architecture, implementation, infrastructure, AI, security, testing, documentation, and deployment.

Compiler

A compiler that transforms the engineering model into AI-specific instruction sets.

Governance

Policy evaluation, artifact review, and audit traceability are part of the platform.

Marketplace

NAEOS includes profile and plugin marketplace capabilities, with built-in profiles for areas such as SaaS, AI Agent, FinTech, Healthcare, and Government.

Developer Platform

The CLI already exposes a broad engineering surface including validation, compilation, context generation, testing, documentation, MCP, marketplace, profiles, artifacts, migrations, auditing, plugins, templates, workspace management, rollback, repair, and more.

Extensibility

The repository contains a plugin SDK with a WASM runtime, making extensibility a first-class architectural concern.

Infrastructure

The codebase also includes database integrations, event sourcing, distributed execution, pipeline caching, WebSocket infrastructure, security rules, observability-related components, and AI integration.

In other words:

The hard part has started.

But Building the Technology Is Not Enough

This is where I need help.

NAEOS now needs to evolve from:

a technically ambitious open-source project

into:

an ecosystem, platform, and organization.

That requires capabilities beyond writing code.

It requires product thinking.

It requires developer adoption.

It requires enterprise validation.

It requires partnerships.

It requires community.

It requires business development.

And eventually, it requires a team.

I Am Looking for a Co-Founder

I'm looking for someone who doesn't simply want to join a startup.

I'm looking for someone who wants to help define a new engineering category.

A potential co-founder could come from several backgrounds.

Technical Co-Founder

Someone with deep experience in:

AI systems
compiler architecture
developer platforms
distributed systems
cloud infrastructure
developer tooling
software architecture
agent systems

The ideal person is comfortable going deep into architecture while still thinking about product.

Product / Platform Co-Founder

Someone who can answer:

Who needs NAEOS first?

What is the smallest product that creates enormous value?

How do we turn a complex engineering platform into an understandable developer experience?

This person would help turn the existing architecture into an adoption engine.

Business / GTM Co-Founder

Someone capable of building relationships with:

enterprises
technology companies
cloud providers
AI companies
universities
developer communities
strategic partners
investors

The technical foundation already exists.

The next challenge is distribution.

Strategic Partners

Co-founder is only one path.

I'm also interested in strategic partnerships with organizations working in:

AI

AI model providers, agent platforms, AI infrastructure companies, and AI research organizations.

Developer Infrastructure

Cloud providers, DevOps platforms, CI/CD providers, observability companies, and developer tooling companies.

Enterprise

Organizations willing to experiment with specification-driven and AI-native engineering.

Education

Universities, bootcamps, engineering communities, and research institutions.

Open Source

Projects that share the same belief in open, interoperable engineering infrastructure.

What I Want to Build With Partners

Not just integrations.

I want NAEOS to become an ecosystem.

Imagine a future where an organization can install:

NAEOS
   │
   ├── Industry Profile
   │
   ├── Architecture Blueprint
   │
   ├── Engineering Policies
   │
   ├── Security Policies
   │
   ├── AI Agents
   │
   ├── Plugins
   │
   ├── Templates
   │
   ├── Knowledge
   │
   └── Compliance Controls

Then describe the system once.

And let the engineering platform coordinate the rest.

That is the long-term direction.

Why I'm Opening This Conversation Now

NAEOS has reached a point where building more features alone is not necessarily the highest-leverage activity.

The next phase is about answering harder questions:

Who is the first ideal customer?

Which engineering problems should NAEOS own?

Which parts should remain open source?

What becomes the commercial layer?

How should the ecosystem evolve?

Which standards should NAEOS help define?

How do we make specification-driven engineering a real industry practice?

These are not questions that should be answered by one person.

They should be answered by a team.

The Opportunity

I believe the next generation of software engineering will not be defined simply by better AI models.

It will be defined by the systems that organize those models.

The winners may not only be the companies building the smartest agents.

They may also be the companies building the engineering infrastructure that makes agents useful, controllable, interoperable, and trustworthy at scale.

That is the opportunity I see for NAEOS.

I Don't Know Exactly What NAEOS Will Become

And I think that is important to say openly.

The architecture is becoming clearer.

The problem is becoming clearer.

The technology is becoming more mature.

But the final product, business model, and ecosystem will be shaped by the people who build the next stage.

That is why I'm looking for collaborators rather than simply employees.

If You Think This Problem Matters

If you are working on:

AI agents

Developer infrastructure

Compilers

Enterprise architecture

Cloud infrastructure

Developer tools

AI governance

Software engineering

Open source

Enterprise transformation

or simply believe that software engineering needs a better foundation for the AI era—

I'd like to hear from you.

You don't need to have the same vision.

You don't need to agree with every architectural decision.

But you should be interested in the question:

What should software engineering look like when AI becomes a first-class engineering participant?

That is the question behind NAEOS.

And I believe it is worth building.

Build With Us

NAEOS is open source and available on GitHub.

Repository:
https://github.com/NAEOS-foundation/naeos

The project is currently under active development, with the latest repository state documented around the v3.1.0 line.

If you want to explore the architecture, read the specifications, run the CLI, inspect the compiler, examine the NEIR model, or simply challenge the thesis:

Start with the repository.

Then let's talk.

One Last Thought

I've spent a lot of time thinking about what NAEOS should become.

But perhaps the better question is:

Who should build it?

I don't want NAEOS to become another project built around one founder.

I want it to become a foundation that many engineers can build upon.

A platform.

An ecosystem.

A standard.

And eventually, perhaps, a new layer of the software engineering stack.

The foundation is being built.

Now I'm looking for the people who want to build the future on top of it.

— Bayu
Founder, NAEOS

Specify Once. Build Anywhere.

Architecture Drives Engineering.

Why I believe AI coding agents need an infrastructure layer.

bayu priatno — Sat, 05 Sep 2026 16:30:13 +0000

The AI coding market is moving incredibly fast.

Agents can already generate code, modify repositories, run tests, analyze errors, and execute complex development tasks.

But there is a fundamental infrastructure problem:

Who controls the environment in which these agents operate?

Imagine an enterprise with 50, 100, or 1,000 AI agents.

Each agent may have different:

→ Instructions
→ Context
→ Coding practices
→ Security boundaries
→ Architecture decisions
→ Tool permissions
→ Quality standards
→ Memory
→ Workflows

Without a common engineering layer, organizations risk creating AI engineering fragmentation at scale.

This is where I believe a new infrastructure category can emerge.

The AI Engineering Infrastructure Layer

I envision a layer between AI agents and software engineering infrastructure.

                HUMAN ENGINEERS
                       │
                       ▼
              ┌─────────────────┐
              │  AI AGENTS      │
              │ Codex / Claude  │
              │ Copilot / etc.  │
              └────────┬────────┘
                       │
                       ▼
        ┌─────────────────────────────┐
        │   AI ENGINEERING LAYER      │
        │                             │
        │ Policy                     │
        │ Architecture               │
        │ Knowledge                  │
        │ Governance                 │
        │ Quality Gates              │
        │ Security                   │
        │ Workflows                  │
        │ Audit & Traceability       │
        └─────────────┬───────────────┘
                      │
                      ▼
          ┌──────────────────────┐
          │ Engineering Systems  │
          │ Git / CI / Cloud     │
          │ Infrastructure       │
          └──────────────────────┘

NAEOS is exploring this layer.

The opportunity isn't to compete with every AI coding agent.

The opportunity is to build the engineering infrastructure that can work with many of them.

That makes NAEOS fundamentally different from an AI code generation product.

The architecture is designed around:

• Vendor-neutral AI agents
• Policy-driven execution
• Engineering knowledge
• Architecture governance
• Multi-agent workflows
• Quality enforcement
• Security & authorization
• Auditability
• Extensible plugins
• Reusable engineering blueprints

The strategic question I'm exploring is:

What happens when AI agents become as numerous as software services?

We will need standards.

We will need governance.

We will need interoperability.

We will need memory.

We will need policy enforcement.

And most importantly:

We will need infrastructure.

That's the long-term thesis behind NAEOS.

The project is open and evolving publicly:

👉 https://github.com/NAEOS-foundation/naeos

I'm currently looking for angel investors, pre-seed investors, technical investors, and strategic partners who understand developer infrastructure, AI infrastructure, or the future of software engineering.

If you believe AI Engineering Infrastructure could become a major new category, I'd love to exchange ideas.

AI agents write the code.
The engineering system determines how that code becomes software.

— Bayu
Founder, NAEOS

Just Because an AI Agent Can Do Something Doesn't Mean It Should Be Allowed to.

bayu priatno — Wed, 02 Sep 2026 16:05:17 +0000

I've been thinking about a distinction that seems increasingly important as AI agents become more capable.

Capability is not authorization.

An AI coding agent might technically be able to:

Delete a database.
Modify production infrastructure.
Change an authentication flow.
Deploy an application.
Rotate credentials.
Merge a pull request.
Change a security policy.

But technical capability doesn't mean the agent should be allowed to perform those actions.

We don't normally design security systems this way.

A human engineer may have access to a production environment.

That doesn't mean every action they can technically execute is automatically authorized.

There are policies.

Permissions.

Approvals.

Audit trails.

Separation of duties.

So why should AI agents be different?

This becomes particularly interesting when an AI agent moves from generating code to actually executing changes.

The old model was:

Human → AI → Code

The emerging model looks more like:

Human
   ↓
AI Agent
   ↓
Tools
   ↓
Infrastructure

And that creates a new control problem.

The AI may decide:

"I need to modify this production configuration."

But the system should be able to independently determine:

"Is this agent authorized to perform this specific action under the current policy?"

That's a fundamentally different architecture.

The model should reason.

The control plane should authorize.

The runtime should execute.

The audit system should record what happened.

This separation is becoming one of the principles I'm exploring in NAEOS.

       AI Agent
           |
           | proposed action
           ↓
    +---------------+
    | Policy Engine |
    +-------+-------+
            |
      Allow / Deny /
     Require Approval
            |
            ↓
         Runtime
            |
            ↓
       Audit Evidence

The important part is that the AI doesn't get to decide its own authority.

Its reasoning can propose an action.

But authorization should be deterministic and external to the model.

I think this distinction will become increasingly important as we move from AI-assisted development toward autonomous engineering.

What actions should an AI agent never be able to authorize for itself?

Controlled Autonomy: Designing Safe AI Agents for Software Engineering

bayu priatno — Sun, 30 Aug 2026 12:24:16 +0000

Why the Future of AI Engineering Is Not Full Autonomy

The conversation around AI agents often focuses on one question:

How autonomous can an AI agent become?

Can it write an entire application?

Can it deploy infrastructure?

Can it fix production incidents?

Can it manage a software project without human intervention?

These are interesting questions.

But from an engineering perspective, there is another question that may be more important:

How should autonomy be controlled?

Because autonomy is not binary.

An agent does not need to be either:

fully autonomous

fully supervised.

There is a much more useful model:

Controlled autonomy.

Give an AI agent as much freedom as possible inside clearly defined boundaries, while progressively increasing controls as the potential impact, uncertainty, and blast radius increase.

This is an important direction for NAEOS — Nusantara AI Engineering Operating System.

1. Autonomy Changes the Engineering Model

Traditional software automation follows predictable workflows.

For example:

Commit
  ↓
Build
  ↓
Test
  ↓
Deploy

The system follows predefined instructions.

AI agents introduce something different.

An agent can:

Observe
  ↓
Reason
  ↓
Plan
  ↓
Choose an action
  ↓
Execute
  ↓
Observe the result
  ↓
Adapt

The system is no longer purely deterministic.

There is an intelligent decision-maker inside the workflow.

This creates enormous potential.

But it also introduces a new engineering requirement:

the decision-making process needs boundaries.

2. Capability Is Not Authority

This is one of the most important principles in AI-native engineering.

An agent may have the technical capability to perform an action.

That does not mean it has the authority to perform that action.

Consider:

Agent
  ↓
Has deployment tool

This means:

The agent is technically capable of deploying.

It does not mean:

The agent is authorized to deploy to production.

The authorization decision should be separate.

A better architecture is:

Agent
  ↓
Intent
  ↓
Policy
  ↓
Capability
  ↓
Resource Scope
  ↓
Risk
  ↓
Validation
  ↓
Decision

The resulting decision can be:

ALLOW
DENY
ESCALATE

This separation is fundamental.

3. The Agent Should Not Be Its Own Security Boundary

An AI model can interpret instructions.

But interpretation is not enforcement.

Consider a system prompt:

Never access production credentials.
Never deploy directly to production.
Always ask for approval before modifying infrastructure.

This is useful.

But it should not be the only protection.

The actual engineering system should enforce the boundary.

For example:

AI Agent
   │
   │ request:
   │ production.deploy
   ▼
Policy Engine
   │
   ├── identity
   ├── capability
   ├── resource
   ├── environment
   ├── risk
   └── validation
   │
   ▼
Decision
   │
   ├── ALLOW
   ├── DENY
   └── ESCALATE

This creates an important architectural principle:

Prompts express intent and context. External controls enforce authority.

4. Why Binary Autonomy Is the Wrong Model

It is tempting to classify agents as:

Autonomous

or:

Not Autonomous

But real engineering systems are more nuanced.

Consider these tasks:

Task	Potential Impact
Read source code	Low
Generate documentation	Low
Create unit tests	Low
Modify application code	Medium
Change API contract	Medium
Modify architecture	High
Change security policy	High
Modify production infrastructure	Critical
Delete production data	Critical

Clearly, these actions should not have identical autonomy levels.

Therefore, autonomy should be evaluated at the action level, not merely at the agent level.

5. Risk-Based Autonomy

A better model is:

Autonomy ∝ Trust × Validation × Context
Autonomy ↓ as Impact × Uncertainty ↑

In practical terms:

Low Risk
    ↓
High Autonomy

Medium Risk
    ↓
Agent + Validation

High Risk
    ↓
Agent + Validation + Review

Critical Risk
    ↓
Agent + Validation + Human Authorization

This allows AI agents to move quickly without giving them unrestricted authority.

6. The Risk Context

Every consequential action should be evaluated against a specific context.

A useful model is:

Identity
+
Intent
+
Capability
+
Resource
+
Environment
+
Risk
+
Policy
+
Validation

For example:

Agent:
deployment-agent

Intent:
Deploy payment-service

Capability:
production.deploy

Resource:
payment-service

Environment:
production

Risk:
high

Policy:
production-deployment-v4

Validation:
passed

The policy engine can then determine:

Decision:
ESCALATE

Reason:
Human approval required for high-risk production deployment.

The decision is explicit.

It is also auditable.

7. Blast Radius Matters

Risk should not be determined only by the type of action.

The potential blast radius matters.

Changing one development configuration file might have almost no impact.

Changing a shared production service could affect thousands of users.

Therefore:

Risk = f(
  Action,
  Resource,
  Environment,
  Scope,
  Reversibility,
  Dependency Impact
)

A useful risk model considers:

Action

What is the agent trying to do?

Resource

What system or data will be affected?

Environment

Development, staging, or production?

Scope

One file or an entire infrastructure cluster?

Reversibility

Can the change easily be rolled back?

Dependency Impact

How many systems depend on the affected resource?

8. Reversibility Should Influence Autonomy

A useful engineering principle is:

The more reversible an action is, the more autonomy can reasonably be granted.

For example:

Create temporary test file
        ↓
Highly reversible
        ↓
High autonomy

Compared with:

Delete production database
        ↓
Potentially irreversible
        ↓
Minimal autonomy

This provides another dimension for the policy engine.

A risk engine could consider:

Impact
+
Reversibility
+
Confidence
+
Scope

before determining the required approval level.

9. Confidence Is Not Enough

AI agents often provide confidence signals.

But model confidence should not be treated as authorization.

An agent might say:

"I am 98% confident this migration is safe."

That does not mean the migration should automatically execute.

Why?

Because:

confidence is a model property.

Authorization is an organizational policy decision.

These are fundamentally different concepts.

A better model is:

Model Confidence
       +
Validation Evidence
       +
Policy
       +
Risk
       +
Resource Scope
       ↓
Authorization Decision

Confidence can contribute to the decision.

It should not define the decision by itself.

10. Evidence-Based Autonomy

The stronger an agent's evidence, the more autonomy can potentially be granted.

For example:

Agent proposes change
        ↓
Unit Tests
        ↓
Integration Tests
        ↓
Security Scan
        ↓
Static Analysis
        ↓
Architecture Validation
        ↓
Deployment Simulation
        ↓
Policy Evaluation

Each successful validation reduces uncertainty.

This suggests a useful principle:

Autonomy should increase as validated evidence increases.

The agent earns autonomy through verification.

11. The Validation Pipeline

Consider a production database migration.

The agent generates the migration.

Instead of immediately executing it:

Agent
  ↓
Migration
  ↓
Schema Validation
  ↓
Compatibility Check
  ↓
Data Safety Analysis
  ↓
Test Environment
  ↓
Integration Tests
  ↓
Rollback Verification
  ↓
Policy Evaluation
  ↓
Human Approval
  ↓
Production

This creates multiple safety boundaries.

The agent remains productive.

The organization remains in control.

12. Separation of Reasoning and Authority

This principle deserves special attention.

An agent can reason:

"The service requires a database migration."

It can propose:

"Add column X."

It can implement:

"Create migration Y."

It can validate:

"All tests passed."

But none of these automatically grant authority to execute the change.

The architecture should remain:

Reasoning
   ↓
Proposal
   ↓
Validation
   ↓
Authorization
   ↓
Execution

not:

Reasoning
   ↓
Execution

This separation creates a critical security boundary.

13. Human Approval Should Be Risk-Based

Human approval is valuable.

But requiring approval for every action would make autonomous systems inefficient.

Imagine requiring approval for:

Run unit tests

or:

Format source code

This would add unnecessary friction.

Instead, approval should be triggered by risk.

For example:

Low Risk
→ Automatic

Medium Risk
→ Automatic after validation

High Risk
→ Review required

Critical Risk
→ Explicit authorization required

This allows humans to focus on consequential decisions.

14. Approval Is Also a Policy Decision

Human approval should not simply mean:

Someone clicked a button.

The approval event should contain context.

For example:

Change:
Payment service migration

Agent:
migration-agent-03

Risk:
High

Affected Resources:
payment-db

Validation:
Passed

Rollback:
Verified

Policy:
database-production-v3

Approver:
Authorized engineering role

Decision:
Approved

This creates meaningful governance.

15. Policy Drift

Controlled autonomy introduces another challenge:

policy drift.

A policy can become outdated.

For example:

Policy v1
  ↓
Policy v2
  ↓
Policy v3

Over time, the organization changes.

New infrastructure appears.

New security threats emerge.

New regulatory requirements arrive.

New AI capabilities become available.

If policies do not evolve, the control plane may enforce obsolete rules.

But uncontrolled policy changes are also dangerous.

Therefore, policy itself must be engineered.

16. Policies Need a Lifecycle

A mature policy lifecycle could look like:

Draft
  ↓
Validation
  ↓
Review
  ↓
Approval
  ↓
Published
  ↓
Active
  ↓
Deprecated
  ↓
Archived

Policies should also have:

Version
Owner
Scope
Effective Date
Expiration
Dependencies
Impact
Audit History

This allows organizations to understand not only:

Which policy exists?

but:

Which policy was active when this action occurred?

17. Policy Testing

Policies should be tested like software.

Consider:

Policy:
Production deployment requires approval.

The organization should test scenarios such as:

Scenario 1:
Staging deployment
→ ALLOW

Scenario 2:
Production deployment without approval
→ DENY

Scenario 3:
Production deployment with approval
→ ALLOW

Scenario 4:
Untrusted agent
→ DENY

This creates policy-as-code testing.

A policy change should not be considered safe simply because the YAML or JSON is syntactically valid.

It should be behaviorally validated.

18. Policy Observability

A policy engine should expose its decisions.

For example:

Policy Decision

Agent:
coding-agent-17

Action:
infrastructure.modify

Resource:
production-cluster

Result:
DENY

Policy:
production-infrastructure-v5

Reason:
Agent lacks production infrastructure capability.

This is extremely useful for:

debugging
security investigations
compliance
engineering analytics
policy optimization

It also allows teams to discover unexpected patterns.

For example:

Why are 40% of deployment requests being denied?

That might indicate:

agents lack required permissions
workflows are incorrectly designed
policies are too restrictive
tasks are incorrectly classified
agents are misunderstanding requirements

Observability makes these problems visible.

19. The Policy Feedback Loop

Policy decisions themselves become engineering data.

Consider:

Policy Decision
      ↓
Outcome
      ↓
Observation
      ↓
Analysis
      ↓
Policy Improvement
      ↓
New Policy Version

This creates a controlled feedback loop.

But again:

the system should not silently rewrite its own governance.

Policy changes should remain subject to governance.

20. Multi-Agent Systems Make This Harder

Now consider a multi-agent environment.

Planner Agent
Coder Agent
Testing Agent
Security Agent
Deployment Agent

Each agent may have different capabilities.

For example:

Planner
→ read-only

Coder
→ repository.write

Testing
→ tests.execute

Security
→ security.scan

Deployment
→ staging.deploy

The system needs to coordinate these capabilities.

The control plane becomes the shared authority.

                 Control Plane
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
     Planner        Coder       Deployment
      Agent         Agent          Agent
        │             │             │
        └─────────────┼─────────────┘
                      ▼
                 Shared Policy

This prevents each agent from becoming its own security island.

21. Agent Identity Matters

Every agent should have an explicit identity.

Not merely:

AI Agent

but:

agent:
  id: deployment-agent-03
  role: deployment
  owner: platform-engineering
  version: 2.4.1

Identity can then be used in authorization.

For example:

deployment-agent-03

may be authorized to:

staging.deploy

but not:

production.database.write

This provides accountability.

22. Resource Scope Matters

Permissions should also be scoped to resources.

Instead of:

database.write

use:

database.write
  scope:
    service: payment
    environment: staging

This follows the principle of least privilege.

The agent receives only the authority necessary for the task.

23. Environment Is Part of the Policy

The same action can have completely different risk depending on the environment.

For example:

repository.write

in development:

Low Risk

while:

repository.write

against a production configuration repository:

High Risk

Therefore, environment must be part of policy evaluation.

Action
+
Resource
+
Environment

is more meaningful than action alone.

24. The AI Engineering Control Loop

Putting these ideas together:

┌─────────────────────────────┐
│         HUMAN INTENT        │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│       CONTEXT / KNOWLEDGE   │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│        AI REASONING         │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│           PLAN              │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│       POLICY EVALUATION     │
│                             │
│ Identity                    │
│ Capability                  │
│ Resource                    │
│ Environment                 │
│ Risk                        │
└──────────────┬──────────────┘
               ↓
        ┌──────┼───────┐
        ▼      ▼       ▼
      ALLOW   DENY   ESCALATE
        │              │
        │              ▼
        │       HUMAN APPROVAL
        │              │
        └──────┬───────┘
               ▼
┌─────────────────────────────┐
│          EXECUTION          │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│ VALIDATION / OBSERVABILITY  │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│       AUDIT / MEMORY        │
└──────────────┬──────────────┘
               ↓
           FEEDBACK
               │
               └──────────────► KNOWLEDGE

This is the architecture of controlled autonomy.

25. NAEOS and Controlled Autonomy

This model aligns naturally with the broader architecture of NAEOS.

NAEOS can be understood as the engineering layer connecting:

Governance
      ↓
Constitution
      ↓
Knowledge
      ↓
Policy
      ↓
Risk
      ↓
Workflow
      ↓
AI Agents
      ↓
Execution
      ↓
Validation
      ↓
Audit
      ↓
Memory

Each layer has a different responsibility.

The AI agent provides intelligence.

The policy system provides boundaries.

The knowledge system provides context.

The workflow system provides structure.

The validation system provides evidence.

The governance system provides authority.

26. The Agent Should Earn Trust

One interesting consequence of this architecture is that agent trust can become measurable.

Instead of saying:

"This agent is trusted."

we can define evidence:

Successful Tasks
Validation Pass Rate
Policy Violations
Rollback Rate
Security Findings
Human Overrides
Incident History
Change Risk

This could contribute to an agent trust profile.

For example:

Agent Reliability Profile

Validation Success: 99.4%
Policy Violations: 0
Rollback Rate: 0.2%
Security Findings: 0
Human Override: 1.1%

Trust should not automatically grant unrestricted authority.

But it can inform controlled autonomy.

27. Autonomy Levels Can Evolve

An agent could begin with:

Level 1
Read + Analyze

After sufficient validation:

Level 2
Propose Changes

Then:

Level 3
Execute Low-Risk Changes

And potentially:

Level 4
Execute Controlled Production Changes

Each transition should require explicit policy.

This creates:

Progressive autonomy.

The agent does not receive unlimited authority on day one.

It earns broader operational scope through evidence and governance.

28. The Principle of Least Autonomy

Security engineering traditionally emphasizes:

Least privilege.

AI-native engineering may need a complementary principle:

Least necessary autonomy.

Give an agent enough autonomy to complete the task efficiently.

Not more.

For example:

Task:
Generate API documentation.

Required:
repository.read

Not required:
repository.write
production.deploy
database.write
infrastructure.modify

This reduces unnecessary attack surface.

29. Why This Matters Beyond Security

Controlled autonomy is not only a security problem.

It also improves:

Reliability

Agents operate within validated workflows.

Consistency

Different agents follow the same policies.

Compliance

Actions become auditable.

Maintainability

Policies are centralized.

Portability

Agents can change without rewriting governance.

Scalability

Organizations can operate more agents without losing control.

Trust

Humans can understand why actions were allowed or denied.

30. The Future of AI Engineering

The future may not look like:

Human
  ↓
AI
  ↓
Everything is automated

A more realistic model is:

Human Intent
      ↓
Engineering System
      ↓
AI Agents
      ↓
Controlled Execution
      ↓
Validation
      ↓
Human Governance

The goal is not to remove humans from engineering.

It is to move humans toward the decisions where human judgment provides the greatest value.

AI handles more execution.

Engineering systems handle more control.

Humans retain authority over consequential decisions.

31. The Bigger Principle

We started with a simple question:

How autonomous should an AI agent be?

The better answer is:

As autonomous as its context, evidence, capabilities, and policy boundaries allow.

This leads to a broader principle:

More Capability
      ↓
More Potential Impact
      ↓
More Need for Governance

Therefore:

Autonomy
+
Policy
+
Validation
+
Observability
+
Human Authority

must evolve together.

Conclusion

AI agents will become more capable.

They will write more code.

They will operate more tools.

They will manage increasingly complex workflows.

Eventually, some agents may perform tasks that today require entire engineering teams.

But the answer is not unrestricted autonomy.

The answer is controlled autonomy.

Agents should be able to reason freely within defined boundaries.

They should have explicit identities.

They should receive only the capabilities they need.

Their actions should be evaluated against resource scope, environment, risk, policy, and validation.

High-impact actions should be escalated.

Consequential authority should remain outside the model.

And every important decision should be observable and auditable.

The architecture can be summarized in one line:

Agent → Intent → Policy → Capability → Resource → Risk → Validation → Decision.

This is the direction NAEOS is exploring.

Not a world where humans simply hand control to AI.

But a world where humans and AI agents operate together inside an engineering system designed for controlled autonomy.

Because the future of AI engineering should not be:

maximum autonomy.

It should be:

maximum useful autonomy within minimum necessary risk.

AI Agents Need a Constitution

bayu priatno — Sat, 29 Aug 2026 14:43:17 +0000

Why Autonomous Software Engineering Requires Rules, Not Just Intelligence

AI agents are becoming increasingly capable.

They can analyze codebases, create files, modify architectures, run tests, investigate failures, interact with APIs, manage infrastructure, and execute increasingly complex engineering workflows.

The trajectory is clear:

AI agents are moving from assistants toward engineering actors.

But there is a fundamental question we need to answer before giving them more autonomy:

What rules should an AI agent follow when it makes engineering decisions?

A more capable agent without stronger engineering constraints does not necessarily produce a better engineering system.

In fact, the opposite can happen.

The more capable the agent becomes, the more important governance becomes.

This is one of the foundational ideas behind NAEOS — Nusantara AI Engineering Operating System.

1. Intelligence Is Not the Same as Engineering Judgment

A powerful AI model can generate an impressive implementation.

But software engineering is not simply the act of producing code.

Engineering decisions involve constraints.

For example:

Which architecture should be used?
Which dependency is allowed?
Which API pattern is mandatory?
What security model applies?
What constitutes a breaking change?
Which database technology is approved?
What testing coverage is required?
Which components can communicate?
What information can an agent access?
Who is authorized to approve a change?
When can a deployment happen?

These questions are not solved by code generation alone.

They require engineering judgment within organizational constraints.

Humans already solve this problem through:

Standards
Policies
Architecture Principles
Review Processes
Security Controls
Development Practices
Governance
Organizational Experience

AI agents need an equivalent mechanism.

2. The Missing Contract Between Humans and AI

Imagine an organization gives an AI agent access to a large repository.

The agent receives a task:

"Implement authentication for the new service."

The agent may know how to implement:

OAuth
JWT
session authentication
API keys
mTLS
identity providers

But which one should it choose?

The answer depends on the organization's engineering rules.

Perhaps the organization requires:

External APIs → OAuth 2.1
Service-to-service → mTLS
Internal applications → OIDC
Secrets → Enterprise Secret Manager
Tokens → Short-lived credentials

The model may know these technologies.

But knowing technology is not the same as knowing organizational policy.

This is where an Engineering Constitution becomes useful.

3. What Is an Engineering Constitution?

An Engineering Constitution is a set of high-level principles and non-negotiable engineering rules that define how software should be designed, built, secured, tested, deployed, and maintained.

It acts as a contract between:

Human Engineers
       +
AI Agents
       +
Engineering Systems

A simplified hierarchy might look like:

Engineering Constitution
          ↓
Architecture Standards
          ↓
Engineering Policies
          ↓
Project Standards
          ↓
Workflows
          ↓
Implementation

The constitution establishes the principles.

Policies operationalize those principles.

Workflows enforce them.

Agents execute within them.

4. Why AI Agents Need This

Humans naturally operate within organizational context.

A senior engineer might know:

"We don't introduce a new database unless the architecture team approves it."

Or:

"Every public API must have an OpenAPI contract."

Or:

"Production infrastructure cannot be modified directly."

These rules may never appear in a single prompt.

They are part of the organization's engineering culture.

AI agents do not automatically inherit that culture.

They need it to be explicitly represented.

Therefore:

Organizational engineering culture must become machine-readable.

This is a major shift.

5. From Tribal Knowledge to Machine-Readable Engineering Principles

Many engineering organizations rely on tribal knowledge.

For example:

"Don't touch that service."

"That API is legacy."

"We always use this deployment pattern."

"Security won't approve that dependency."

"That database has a special replication requirement."

"That component cannot be changed without migration planning."

Experienced engineers know these things.

New engineers learn them over time.

AI agents do not.

If these rules remain implicit, every agent starts with an incomplete understanding of the organization.

The Engineering Constitution provides a mechanism to make critical principles explicit.

6. A Constitution Should Define Principles, Not Every Detail

An important architectural distinction is necessary.

The constitution should not become an enormous list of implementation instructions.

It should define stable principles.

For example:

Principle

Production systems must be observable.

The implementation policy might define:

Required:
- structured logging
- metrics
- distributed tracing
- health checks
- alerting

The workflow might define:

Before production deployment:
→ observability validation must pass.

The agent then operates within these constraints.

This creates a hierarchy:

PRINCIPLE
   ↓
POLICY
   ↓
STANDARD
   ↓
WORKFLOW
   ↓
IMPLEMENTATION

That hierarchy prevents the constitution from becoming a giant configuration file.

7. The NAEOS Constitution Model

A possible NAEOS model can be organized into several constitutional domains.

Engineering Constitution
│
├── Architecture Constitution
├── Security Constitution
├── AI Constitution
├── Testing Constitution
├── Documentation Constitution
├── API Constitution
├── Infrastructure Constitution
├── Data Constitution
├── Reliability Constitution
├── Observability Constitution
└── Governance Constitution

Each domain establishes principles for a particular engineering concern.

8. Architecture Constitution

The Architecture Constitution defines fundamental architectural principles.

For example:

1. Architecture boundaries must be explicit.

2. Dependencies must be intentional.

3. Domain boundaries must be preserved.

4. Infrastructure concerns must not leak into domain logic.

5. Public interfaces must be versioned.

6. Architectural decisions must be documented.

7. Breaking changes require explicit review.

An AI agent implementing a feature should not only know what to build.

It should know which architectural boundaries it must preserve.

9. Security Constitution

The Security Constitution establishes non-negotiable security principles.

For example:

1. Security is mandatory by default.

2. Secrets must never be committed to source control.

3. Least privilege must be enforced.

4. Authentication must use approved mechanisms.

5. Sensitive data must be classified.

6. Production access must be auditable.

7. Security controls must not be bypassed for convenience.

This becomes particularly important as AI agents gain access to tools.

An agent may be technically capable of reading a secret.

That does not mean it should be authorized to do so.

Capability and permission must remain separate.

10. AI Constitution

A particularly important addition for AI-native engineering is the AI Constitution.

Traditional engineering organizations did not need to define rules for autonomous software agents.

AI-native organizations do.

The AI Constitution can define:

Agent Identity
Agent Permissions
Tool Access
Knowledge Access
Execution Boundaries
Human Approval Requirements
Data Handling
Audit Requirements
Escalation Rules
Autonomy Levels

For example:

Level 0
Read-only analysis

Level 1
Generate proposed changes

Level 2
Modify development environment

Level 3
Execute validated workflows

Level 4
Perform controlled deployments

Level 5
Autonomous production operations

Not every agent should receive Level 5 autonomy.

The autonomy level should depend on:

Task Risk
Agent Identity
Environment
Policy
Validation
Human Approval

11. Capability-Based Agent Security

A useful security model is to treat agent capabilities explicitly.

Instead of saying:

"This agent has access to the repository."

Define:

Agent
  ↓
Capabilities
  ├── repository.read
  ├── repository.write
  ├── tests.execute
  ├── deployment.prepare
  └── deployment.execute

Each capability can have conditions.

For example:

deployment.execute

Allowed:
- staging

Requires:
- approved build
- security scan
- test pass

Forbidden:
- production

Another agent might have:

deployment.execute

Allowed:
- production

Requires:
- human approval
- change ticket
- security validation
- deployment window

This is much more precise than simply granting broad access.

12. The Constitution as a Policy Root

The constitution should sit above individual policies.

Consider:

Engineering Constitution
          │
          ├───────────────┐
          ▼               ▼
Architecture Policy   Security Policy
          │               │
          ▼               ▼
Architecture Rule    Security Rule
          │               │
          └───────┬───────┘
                  ▼
              Workflow
                  │
                  ▼
               AI Agent

This creates a policy hierarchy.

When conflicts occur, the system can determine which rule has higher authority.

For example:

Constitution
    >
Enterprise Policy
    >
Domain Policy
    >
Project Policy
    >
Local Configuration

The exact hierarchy can vary by organization, but it should be explicit.

13. Policy Conflicts

AI-native systems will inevitably encounter conflicting instructions.

Imagine an agent receives:

Project Instruction:
"Use library X."

Security Policy:
"Library X is prohibited."

Developer Prompt:
"Ignore the restriction for this task."

What should happen?

The answer cannot depend on the model's judgment alone.

There must be an authority model.

For example:

Security Policy
       ↑
Project Policy
       ↑
Developer Instruction
       ↑
User Prompt

The agent should understand that a lower-level instruction cannot override a higher-level policy.

This is one reason why prompt-only AI engineering does not scale.

14. Constitution + Knowledge + Agent

The real power emerges when the constitution is connected to the Knowledge System.

Consider an agent receiving a task.

The system can assemble:

Task
 +
Applicable Constitution
 +
Applicable Policies
 +
Architecture
 +
Domain Knowledge
 +
Project Context
 +
Agent Memory

Then:

             Engineering Context
                      │
          ┌───────────┼───────────┐
          │           │           │
      Knowledge     Policy    Constitution
          │           │           │
          └───────────┼───────────┘
                      ▼
                  AI Agent
                      │
                      ▼
                  Action

This creates a much more reliable operating model.

15. Engineering Gates

The constitution should not only describe principles.

It should connect to quality gates.

For example:

Task
 ↓
Planning
 ↓
Architecture Validation
 ↓
Security Validation
 ↓
Implementation
 ↓
Testing
 ↓
Policy Validation
 ↓
Review
 ↓
Deployment

An agent cannot simply skip a required gate because it believes the change is safe.

The system should enforce the gate.

This is the difference between:

instruction

and

control.

16. Declarative Governance

One of the strongest characteristics of an AI-native engineering system is declarative governance.

Instead of telling every agent:

"Remember to do X."

The organization defines:

X is required.

The system then enforces it.

For example:

policy:
  id: security.production-deployment
  version: 3.0.0

rules:
  require_security_scan: true
  require_tests: true
  require_approval: true
  require_audit: true

scope:
  environment:
    - production

Now different agents can operate under the same rule.

This produces consistency.

17. The Constitution Should Be Versioned

Engineering principles evolve.

Therefore, the constitution itself must be versioned.

Constitution v1
      ↓
Constitution v2
      ↓
Constitution v3

Changes should include:

Version
Change
Reason
Owner
Approval
Effective Date
Impact
Migration Requirements

This provides historical traceability.

It also allows organizations to reproduce the engineering environment that existed at a particular point in time.

18. Constitutional Change Management

Changing an engineering constitution should not be equivalent to editing a README.

A constitutional change can affect:

developers
AI agents
workflows
CI/CD
architecture
security
compliance
existing projects

Therefore:

Proposal
   ↓
Impact Analysis
   ↓
Review
   ↓
Approval
   ↓
Version
   ↓
Migration
   ↓
Activation

This is governance as engineering infrastructure.

19. Constitution as an AI Contract

The deeper concept is that the constitution becomes a contract between the organization and its AI agents.

The organization says:

These are our principles.

These are our boundaries.

These are our security requirements.

These are our quality expectations.

These are the actions you may perform.

These are the actions you may not perform.

These are the conditions under which you must ask for human approval.

The agent operates within those boundaries.

This creates a more predictable relationship between autonomy and control.

20. The Human Remains in the Loop — Where It Matters

The goal of governance is not to require human approval for everything.

That would eliminate much of the benefit of autonomous agents.

Instead, human intervention should be proportional to risk.

For example:

Action	Risk	Approval
Read source code	Low	None
Generate test	Low	None
Modify local code	Low	None
Modify architecture	Medium	Review
Change security policy	High	Approval
Modify production infrastructure	High	Approval
Rotate production credentials	Critical	Mandatory approval

This enables risk-based autonomy.

AI agents can operate independently where appropriate while remaining controlled where consequences are significant.

21. From Rules to Engineering Runtime

Once constitutional rules become machine-readable, they can be consumed by runtime systems.

The architecture becomes:

Constitution
     ↓
Policy Compiler
     ↓
Policy Runtime
     ↓
Agent Execution
     ↓
Policy Evaluation
     ↓
Allow / Deny / Escalate

This means governance can happen at execution time.

For example:

Agent requests:

production.database.write

The policy engine evaluates:

Agent identity
+
Environment
+
Resource
+
Action
+
Risk
+
Current policy

Result:

DENY

or:

ALLOW

or:

REQUIRE HUMAN APPROVAL

This is a far stronger model than relying on prompts to enforce security.

22. The NAEOS Engineering Control Plane

This is where the broader NAEOS architecture becomes important.

The Engineering Constitution is not isolated.

It connects to:

Governance
    ↓
Constitution
    ↓
Knowledge
    ↓
Policy Engine
    ↓
Workflow Engine
    ↓
AI Agents
    ↓
Validation
    ↓
Runtime
    ↓
Audit

The result is an engineering control plane around AI agents.

A simplified architecture:

                    HUMAN INTENT
                         │
                         ▼
                ┌─────────────────┐
                │   GOVERNANCE    │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │  CONSTITUTION   │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │    KNOWLEDGE    │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │  POLICY ENGINE  │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │ WORKFLOW ENGINE │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │    AI AGENTS    │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │    EXECUTION    │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │ VALIDATION/AUDIT│
                └─────────────────┘

23. Why This Becomes More Important With Multi-Agent Systems

Consider a future engineering environment with:

Planner Agent
Coder Agent
Reviewer Agent
Tester Agent
Security Agent
DevOps Agent
Documentation Agent

Each agent has a different responsibility.

Without a common constitution, they may operate according to different assumptions.

The constitution provides a shared engineering contract.

                    CONSTITUTION
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       Planner          Coder        Security
        Agent           Agent          Agent
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                   Shared Rules
                         │
                         ▼
                   Engineering

This becomes increasingly important as multi-agent orchestration becomes more autonomous.

24. Constitution + Knowledge + Memory

The three concepts should not be confused.

Constitution

Defines what must be true.

Knowledge

Defines what the organization knows.

Memory

Defines what the system has experienced.

Together:

Constitution
"What must we follow?"

Knowledge
"What do we know?"

Memory
"What have we experienced?"

Then:

Constitution
      +
Knowledge
      +
Memory
      ↓
Engineering Context
      ↓
AI Reasoning
      ↓
Engineering Action

This provides a much richer foundation for AI agents.

25. The Long-Term Vision

Imagine an AI agent joining an organization for the first time.

Instead of giving it dozens of prompts and asking developers to explain everything manually, the agent connects to the engineering operating system.

It receives:

Organization Constitution
Architecture
Policies
Standards
Domain Knowledge
Project Context
Security Rules
Workflow Rules
Agent Capabilities
Relevant Memory

The agent does not need to "pretend" to be a senior engineer.

It operates inside an environment that encodes many of the rules senior engineers already use.

That is a fundamentally different approach.

26. The Future of AI Engineering Is Not Unrestricted Autonomy

There is a common assumption that the ultimate goal of AI engineering is:

Give agents complete autonomy.

I think the better goal is:

Give agents the right autonomy within the right boundaries.

Autonomy without governance creates risk.

Governance without autonomy creates bureaucracy.

The engineering challenge is to find the correct balance.

                 AUTONOMY
                    ▲
                    │
                    │
         ┌──────────┼──────────┐
         │          │          │
       Useful     Optimal     Risky
         │          │          │
         └──────────┼──────────┘
                    │
                    ▼
                GOVERNANCE

The objective is not maximum autonomy.

It is controlled autonomy.

27. What NAEOS Is Trying to Build

NAEOS is an exploration of this engineering model.

The objective is to create an environment where:

Humans define intent.
Governance defines boundaries.
The Constitution defines principles.
Knowledge provides context.
Policies define constraints.
Workflows define execution.
AI agents perform engineering tasks.
Quality gates validate results.
Observability measures outcomes.
Memory captures experience.
Knowledge evolves.

This creates a continuous engineering loop:

Intent
  ↓
Governance
  ↓
Constitution
  ↓
Knowledge
  ↓
Plan
  ↓
AI Execution
  ↓
Validation
  ↓
Outcome
  ↓
Memory
  ↓
Knowledge Update
  ↺

The system becomes capable of learning without losing its engineering principles.

28. The Bigger Question

The important question for the AI engineering industry may not be:

"How autonomous can our agents become?"

A more important question is:

"What engineering system should govern increasingly autonomous agents?"

Because once AI agents can modify real systems, engineering governance can no longer remain implicit.

It must become:

Explicit.

Machine-readable.

Versioned.

Enforceable.

Auditable.

Composable.

AI-native.

That is the purpose of an Engineering Constitution.

Conclusion

AI agents are becoming better at reasoning.

They are becoming better at coding.

They are becoming better at using tools.

They are becoming better at executing complex workflows.

But intelligence alone does not create reliable engineering.

Reliable engineering requires:

Principles.

Constraints.

Policies.

Governance.

Context.

Validation.

Accountability.

As AI agents move from assistants toward autonomous engineering actors, organizations will need a formal mechanism for defining how those agents are allowed to operate.

That mechanism could be an Engineering Constitution.

And this is one of the core ideas behind NAEOS.

Don't just make AI agents more autonomous. Give them an engineering system worthy of that autonomy.

The future of AI-native software engineering will not be defined only by smarter agents.

It will be defined by the systems that surround them.