Kernel
Deterministic foundation
Identity, scope, state transitions, authorisation and evidence.
Project · AECP
AshaCore Engineering Control Plane
Agents rebuild what already exists, context is expensive and the overview gets lost in the chat history. AECP keeps orders, ownership, execution and proof as a system outside the chat. AgnoOS is the engine and the Command Center the interface.
Structure
A control system made of clearly bounded building blocks.
Kernel, execution, runtime, graph, adapters, context, API and interface form one chain. The domain chain is: Intent → Feature → Work Item → Plan → Workflow → Activity → Run → Evidence.
Execution
Controlled runs
Workspaces, Git binding, leases, execution envelopes and budgets.
Durable Runtime
Durable flows
Steps, wait/signal, retries, checkpoints, recovery and cancellation.
Graph projection
Recoverable execution graph
Built from intents, work items, plans, runs, evidence, dependencies and blockages out of the events; recoverable at any time, never a second source of truth.
Agent adapters
Provider-independent execution
One adapter per provider.
Ergon
Local model
Within AECP for routing and static tasks, so expensive models are not paid for administrative turns.
Context / Knowledge
Context with provenance
Context packs, retrieval, provenance, freshness, compaction and budget limits.
API / MCP
Typed boundaries
Commands and read models for the CLI, MCP and interface; unknown capabilities are rejected fail-closed.
Command Center
Explains and triggers
Dashboard for state, orders, runs, agents, events, approvals and statistics; it bypasses no policy.
The command pipeline is: authenticate → validate → expected version → capability → risk → transition → evidence → transaction → event → typed result. An agent never sets something to “done”: Kernel, evidence and verification decide between completed, verification pending or rejected.
Harnessing
Capable models need a dependable operating framework.
Harnessing determines which information an agent receives, which tools it may use, when a human decides and how an outcome is measured. Goal, scope, budget and approvals turn an open conversation into reviewable work.
Principle
A prompt does not grant permission
The runtime checks identity, preconditions, permissions and side effects independently of the model. Human approval authorises a specific action; it neither grants blanket access nor proves that execution happened.
Human-in-the-Loop
Accountability stays in the right place.
People set direction, decide on risk and approve external impact. Agents take on bounded work within the mandate they receive.
Principle
Approval is a concrete decision
A human confirms a specific action or defined transition. That creates neither permanent authority nor proof that execution succeeded.
Evidence-gated Completion
Completion requires acceptance.
An agent submits a completion claim. The combination of work state, result artefact, tests, evidence and independent verification decides the state.
Principle
Claim and completion stay separate
Stale state, missing evidence or a policy violation lead to verification pending or rejection. Plausible answers and ended processes are not completion proof.
Execution Graph
Dependencies remain visible.
The execution graph is built from events and projects intents, work items, plans, runs, evidence, dependencies and blockages. It is recoverable and never a second source of truth.
Principle
Readable relationships instead of chat history
The Command Center shows who owns a step, what is proven, what is waiting and which decision is missing.
Durable Execution
Flows can wait, restart and stop.
Steps, wait/signal, retries, checkpoints, recovery and cancellation form the durable runtime. Domain workflow semantics remain separate from the replaceable runtime.
Principle
State survives the individual turn
A run is one concrete attempt with its own state, work state and result. Controlled retries and resumption need a traceable proof.
Context Engineering · RAG
The right knowledge for the right task.
Context Engineering brings together context packs, retrieval, provenance, freshness, compaction and budget limits. RAG supplies context; it does not replace permissions or answer verification.
Principle
Sources before similarity
Project, access and applicable version define the search. Summaries retain their sources; conflicting claims are checked against the original passage.
Current building blocks
Today's technical state.
Building blocks are replaceable behind adapters; this list describes today's state.
Technology
Implementation today
Kernel in Python · PostgreSQL as canonical state with event log and outbox · graph projection currently Ladybug (embedded) · durable runtime currently DBOS · local model currently Qwen via llama.cpp · agent adapter currently for Codex, with further providers prepared.
Current status
Three equal fields for the engineering system: no percentage, only the documented state of the work.
Documented
- The knowledge repository and its records are documented as completed foundations.
- Governance bridges and agent profiles are complete.
- Contracts are complete and the shared starting point is ratified.
- The smoke test as a prerequisite is complete.
In progress
- The next build phase connects the kernel foundations with the first delivery steps.
- Token, context and launcher optimisation continues as agent-run efficiency work.
- The Command Center is making state, orders, runs, events, agents, statistics and approvals live through the existing API.
Next proof
- The durable runtime receives its go proof next.
Structure
Building blocks of the control system.
The building blocks show responsibility boundaries, not a maturity ladder.
Kernel
Deterministic foundation
Identity, scope, state transitions, authorisation and evidence.
Execution
Controlled runs
Workspaces, Git binding, leases, execution envelopes and budgets.
Command Center
Explains and triggers
Dashboard for state, orders, runs, agents, events, approvals and statistics; it bypasses no policy.
Documented state
What supports the current description.
These statements summarise the internally documented engineering state; they are not a public availability promise.
Work flow
From intent to proof
The domain chain connects intent, feature, work item, plan, workflow, activity, run and evidence.
Completion
Claim and completion stay separate
An agent submits a completion claim; Kernel, evidence and verification decide between completed, verification pending or rejected.
Principles
Clear boundaries for people and agents
Harnessing, Human-in-the-Loop and Evidence-gated Completion keep order, execution and proof distinct.