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?
Top comments (0)