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