AgenticNetsOS: The First Production-Ready Multi-Agent Orchestration Runtime

AgenticNetsOS: The First Production-Ready Multi-Agent Orchestration Runtime

Your agents are running naked. No runtime. No sandbox. No credential isolation. No audit trail. No kill switch. AgenticNetsOS changes this — fundamentally. Not by adding guardrails to the existing model, but by providing an entirely different one: a governed runtime where every action is traceable, credentials never touch agents, and everything is created by prompting.

The Problem: Agents Without Governance

Picture this. It’s 3 AM. An AI agent you deployed last week is running autonomously. It’s making API calls to your customer database. It’s generating code and pushing changes. It’s executing shell commands on a payment processing server. The logs say it completed 27 tasks and made 41 API calls.

Then your phone buzzes. The agent hit a rate limit. Instead of backing off, it retried 43 times. Two hundred dollars in API credits burned. Worse — it opened a pull request overwriting a critical configuration file. The CI pipeline picked it up and started deploying. Nobody was watching.

You need to understand what happened. You open the conversation window. It’s gone. The session expired. The agent’s reasoning — why it retried, what data it saw, what alternatives it considered — all vanished. The logs show what happened but not why.

This is the reality of most agent frameworks today. They solve the “how do I call an LLM” problem brilliantly. But they leave three critical problems unsolved:

• Invisible state — You can’t see the intermediate data the agent is working with, the conditions it’s evaluating, or the tokens it has consumed and produced.
• Ephemeral memory — Everything vanishes between sessions. Every pattern discovered, every lesson learned — gone. The agent is perpetually a first-day employee.
• Ungoverned execution — No permission tiers. No structured boundaries. The agent either has access to everything or nothing.

These aren’t edge cases. They’re why most agent deployments never leave the proof-of-concept stage. Security teams block deployment because they can’t audit agent behavior. Finance blocks it because they can’t control costs. Operations blocks it because there’s no way to manage or stop agents structurally.

The Solution: A Runtime for Agents

AgenticNetsOS provides what no other framework offers: a governed runtime where agents operate inside a managed environment. Not on your machine with full access. Inside a runtime that controls what agents see, what they can do, where their output goes, and records everything.

Think about the difference between running a script directly on your machine vs. running a program inside an operating system. The OS manages memory, controls file access, enforces permissions, tracks resources, and provides structured lifecycle management. AgenticNetsOS is that operating system, but for AI agents.

When an agent needs to interact with the outside world — call an API, execute a shell command, access a database — it doesn’t do it directly. It creates a request token. That request flows through the runtime to a dedicated execution channel. The execution channel handles authentication, timeout, retry, and result capture. The result flows back. The agent never touches credentials. The agent never makes untracked external calls.

Everything by Prompting

Here’s what using AgenticNetsOS actually looks like. You open a terminal:

$ agenticos chat
You: Create a monitoring agent that watches application logs,
     identifies error patterns, and creates tickets for recurring issues.

Agent: [THINK] Planning net topology...
Agent: [CREATE_PLACE] p-incoming-logs (task)
Agent: [CREATE_PLACE] p-error-patterns (learning)
Agent: [CREATE_PLACE] p-tickets (task)
Agent: [CREATE_TRANSITION] t-parse-logs (map)
Agent: [CREATE_TRANSITION] t-classify-errors (llm)
Agent: [CREATE_TRANSITION] t-match-patterns (pass)
Agent: [CREATE_TRANSITION] t-create-ticket (agent)
Agent: [CREATE_ARC] p-incoming-logs → t-parse-logs → ...
Agent: [DEPLOY_TRANSITION] all transitions deployed
Agent: [START_TRANSITION] all transitions active
Agent: ✓ Monitoring pipeline created and running.

No code. No YAML. No pipeline configuration. You described what you wanted. The system built a living, running, governed workflow inside the runtime. The agents it created are not loose scripts — they’re processes inside a managed environment with explicit permissions, traceable actions, and controllable lifecycles.

Three channels give you the same power: the CLI in your terminal, a Telegram bot on your phone, and a visual editor in your browser. But the GUI is not where you work — it’s where you observe. The control surface is your voice, your prompts, your natural language. The GUI shows you what’s happening: the full topology, real-time token flow, the state of every agent.

The Heart of AgenticNetsOS: Agent Transitions and the Net-as-Agent Paradigm

Everything described so far — the runtime, the prompting, the credential isolation — is infrastructure. The idea that makes AgenticNetsOS fundamentally different from every other framework lives in a single concept: a net can be a workflow, or a net can be an agent. The difference is which transitions you use.

Two Kinds of Transitions, Two Kinds of Intelligence

AgenticNetsOS has seven transition types. Three are deterministic — pass (routing), map (transformation), and HTTP (API calls). They always produce the same output for the same input. No AI involved. Zero cost beyond compute. Infinitely reliable.

Two are non-deterministic — LLM (single-shot inference) and Agent (autonomous multi-step reasoning). They use AI to reason, classify, investigate, and create. They are powerful, flexible, and they cost money.

When you build a net using only deterministic transitions, you get a workflow: data flows in, gets routed, transformed, and forwarded. Predictable. Auditable. Cheap. Like a traditional pipeline.

When you add agent transitions to the same net, something qualitatively different happens. The net becomes an agent. It can reason about its inputs. It can investigate. It can create new data structures the designer never anticipated. It can follow knowledge graph connections to discover context. It can call 42 tools to inspect, build, and operate within the runtime. The net thinks.

And here’s the key insight: you mix both in the same net. Deterministic transitions handle the parts that don’t need intelligence — routing, transformation, API calls. Agent transitions handle the parts that do — investigation, classification, creative problem-solving. The net is a hybrid: part workflow, part agent. The deterministic parts are fast and free. The intelligent parts are powerful and bounded.

What Makes Agent Transitions Special

Agent transitions are fundamentally different from every other transition type. They don’t just process data — they build, explore, and reshape the runtime itself.

They create, not transform. A map transition reshapes input into a predefined output schema. An LLM transition returns a classification — single-shot, bounded. An agent transition creates entirely new output based on what it discovers. You give it a task: “Investigate this error.” It might produce a 3-field summary or a 20-field root cause analysis depending on what it finds. The output structure is determined by the task, not by a template.

Presets are optional, postsets are required. Unlike deterministic transitions that must know their inputs, agents can discover data autonomously — querying any place, following knowledge graph links, inspecting the full net structure. But they must have defined output places. The net always knows where results will land, even if it can’t predict what those results look like.

Agents That Build Structure: 42 Tools for Runtime Manipulation

This is what truly separates AgenticNetsOS from every other agent framework. Agent transitions don’t just think — they act on the runtime itself. They can create new nets, add places, wire transitions, set inscriptions, populate tokens, and even deploy what they build. They are agents that build agents.

The 42 tools are organized across four categories:

Read tools (18) — The agent’s eyes. QUERY_TOKENS to search data across any place using ArcQL. LIST_PLACES and GET_PLACE_INFO to discover what containers exist. GET_NET_STRUCTURE and EXPORT_PNML to understand the full topology of any net in the current session. GET_LINKED_PLACES to navigate knowledge graph connections. EXTRACT_TOKEN_CONTENT to read large tokens in different modes — text, links, structure, head, or summarize. LIST_ALL_SESSIONS and LIST_SESSION_NETS to discover other nets running in the same workspace. The agent can see everything — its own net, other nets, all tokens, all structure.

Write tools (13) — The agent’s hands. CREATE_TOKEN and DELETE_TOKEN to manage data. But far more powerful: CREATE_PLACE, CREATE_TRANSITION, CREATE_ARC to build entirely new net structure. SET_INSCRIPTION to define the logic for transitions it creates. CREATE_NET and DELETE_NET to manage complete nets. NET_DOCTOR to diagnose and heal broken configurations. EMIT_MEMORY to write learnings back to its own context. An agent with write access can design a complete workflow from scratch — places, transitions, arcs, inscriptions, seed tokens — all created through autonomous reasoning.

Execute tools (10) — The agent’s authority. DEPLOY_TRANSITION to activate what it built. START_TRANSITION and STOP_TRANSITION to control lifecycle. FIRE_ONCE and EXECUTE_TRANSITION_SMART to trigger other transitions. DOCKER_RUN, DOCKER_STOP, DOCKER_LIST, DOCKER_LOGS to manage containers. An agent with execute access can not only design a workflow but deploy it, activate it, and orchestrate it.

HTTP tools (1) — The agent’s outside reach. HTTP_CALL makes external requests. This is the most privileged capability — the ability to reach beyond the runtime entirely.

Security Through Permission Tiers: The rwxh Model

These 42 tools are not available to every agent. Access is controlled through a Unix-inspired permission model with four flags: read (r), write (w), execute (x), and HTTP (h). Each flag unlocks a tool tier. Each tier includes all tools from lower tiers.

The critical security boundary: a rw-- agent — the default role — can design a complete workflow with places, transitions, arcs, and inscriptions. It can create elaborate multi-agent systems. But it physically cannot deploy or activate what it built. The deploy and start tools don’t exist at that permission level. A human reviews the design, approves it, and deploys it. The agent proposes. The human decides.

This enables a graduated trust model:

• Day 1: New agent gets r---. It can only observe and report. You watch its behavior.
• Week 2: Promote to rw--. It can now design workflows. You review and deploy them.
• Month 2: Promote to rwx-. It can deploy and operate its own workflows. You monitor.
• Trusted environments: rwxh. Full autonomy. External access. For proven agents in controlled settings.

Trust is earned through observable behavior in a transparent runtime — not granted upfront and hoped for the best.

Cross-Net Awareness: Agents That See Beyond Their Own Net

Agent transitions are not confined to their own net. Using LIST_ALL_SESSIONS, LIST_SESSION_NETS, and GET_NET_STRUCTURE, an agent can discover and inspect other nets running in the same session. It can query tokens from places in other nets. It can follow knowledge graph links that span net boundaries. It can understand the full topology of everything running in its workspace.

This enables powerful patterns:

• Orchestrator agents that scan all running nets, identify problems, and create fix workflows on the fly.
• Designer agents that read the structure of an existing net, understand its patterns, and extend it with new capabilities.
• Monitor agents that observe token flow across multiple nets and produce cross-system health reports.
• Self-healing agents that detect stuck transitions in other nets, diagnose the issue using NET_DOCTOR, and propose or apply fixes.

An agent in Net A can read a result token from Net B, use it to create a new transition in Net C, and set the inscription based on patterns it discovered in Net D. Agents that build agents, governed by the same permission model, all within a single auditable runtime.

Four Place Categories: An Agent’s Memory

What makes a net function as an agent rather than just a pipeline? Four types of places that serve as structured memory:

• Task places hold work items. Tokens are consumed when processed — they drive progress. “Analyze this log file.” “Review this pull request.”
• Context places hold ground truth. Tokens are kept on read — they constrain decisions without being destroyed. API documentation, coding standards, architectural rules.
• Tool places hold available capabilities. Tokens describe what MCPs, APIs, and external tools are available and how to use them. Also kept, not consumed.
• Learning places hold patterns the agent has discovered. These evolve over time — each execution can add new lessons. “This API requires OAuth2 not Basic Auth.” “Connection pool exhaustion during batch jobs resolves by rescheduling.”

An agent transition reads all four categories. Task places tell it what to do. Context places tell it how the world works. Tool places tell it what capabilities are available. Learning places tell it what it learned before. The result: a system that gets smarter with every execution because knowledge accumulates structurally, not in ephemeral conversation windows.

The Crystallization Path: From Agent to Workflow

Here’s where the two paradigms converge in the most elegant way. Every agent net naturally evolves toward a workflow net:

• Week 1: Agent transition handles everything. Full AI reasoning for every task. Expensive, flexible, learning.
• Week 2: Agent notices a recurring pattern: “I keep classifying these errors the same way.” It proposes: “Replace this agent step with a pass transition using a condition on the error-code field.”
• Week 3: Human approves. The agent transition becomes a pass transition. Zero AI cost for that step. Forever.
• Month 3: 80% of the net is deterministic. The agent handles only genuinely novel cases. The net evolved from agent to workflow — through use, not through redesign.

This is pattern crystallization. AI reasoning hardens into deterministic logic. Intelligence becomes infrastructure. The net starts as an agent and matures into a workflow, keeping agent transitions only where true intelligence is needed. Your costs go down. Your reliability goes up. And the transition is organic — the system tells you when a pattern is ready to crystallize.

Five Enterprise Properties No Other Framework Provides

AgenticNetsOS is the first production-ready multi-agent orchestration runtime. This is a specific technical claim based on five requirements that production deployments need and no other framework provides in combination:

1. Credential Isolation

Agents never see production credentials. Credentials are stored in an encrypted vault (OpenBao, AES-256-GCM at rest) on an isolated internal network. When an executor fires an HTTP or command transition, it fetches credentials from the vault just-in-time, injects them into the execution context, and discards them when done. Credentials never become token properties, never flow through the data model, never appear in the event log.

Credential rotation is seamless — update the vault, the next firing fetches the new credential. No restart, no redeployment, no agent reconfiguration. The agent doesn’t even know the rotation happened.

2. Full Audit Trail

The entire system is built on event sourcing. Every token created, consumed, transition fired, and tool called is an immutable event. Not logs — events. Logs can be incomplete or missing. Events are immutable and complete. You can replay the exact sequence of decisions any agent made at any point in time. Regulatory compliance becomes a query, not a project.

3. Operational Control

Every transition has an explicit lifecycle: deployed, running, stopped. Stop a single transition, a workflow, or the entire system. State is preserved — stopping is not destructive. Tokens remain in their places. Resume and the system picks up exactly where it left off. Agents operate under a Unix-style permission model (rwxh): read, write, execute, HTTP — each tier adds capabilities. A read-write agent can design workflows but physically cannot deploy them.

4. Cost Visibility & Control

Every LLM call, API call, and command execution is a measurable event tracked through Prometheus. Cost per agent, per workflow, per day. But AgenticNetsOS also reduces costs over time through pattern crystallization: agent reasoning hardens into deterministic transitions. The log analyzer’s first investigation costs ~$0.05. The second encounter of the same pattern? $0.0001. 500x cheaper. By month two, 80% of events are handled deterministically.

5. Multi-Agent Coordination

Agents work together with explicit data handoffs through shared token pools — not through shared conversation contexts. Atomic compare-and-swap token consumption means no race conditions, no duplicate processing, no lost data. Two agents never accidentally process the same item. Guaranteed by the mathematical foundation, not by careful coding.

The Executor Pattern: How Agents Reach the Outside

The executor is the architectural decision that makes all of this secure. Two kinds of processing exist in AgenticNetsOS:

• Inside the runtime (master): Agents read data, reason, create new data, route decisions. The thinking layer.
• Outside the runtime (executor): Commands execute on remote machines, API calls reach external services. The doing layer.

The executor is a separate service that polls the master every 2 seconds. Egress-only. No inbound connections. No open ports. No VPN. No firewall rules. It works behind corporate firewalls, in air-gapped networks, on developer laptops — anywhere with outbound access.

When the master has a command to execute:

• The executor picks up the work token
• The executor (not the agent) fetches credentials from the vault
• The executor runs the command locally with injected credentials
• The executor captures stdout, stderr, exit code, duration
• The executor posts results back as new data tokens

The agent sees results. The agent never sees credentials. The agent never touches the external system directly. This is the virtual runtime concept — agents think they’re making things happen. In reality, they create requests that flow through a governed execution channel.

What’s Running Today

These are production systems with real metrics, not roadmap items:

Autonomous Code Review & Fix Pipeline

Three interconnected agent networks reviewing code across eight modules in parallel. Each module gets a dedicated review agent → fix agent → build → test → verification. Real result: discovered and fixed a HIGH-severity path injection vulnerability in the vault service in 6 minutes. The agent identified unvalidated path parameters allowing directory traversal, wrote the fix and the tests.

Self-Improving Log Analyzer

19 places, 12 transitions, 6 functional zones. Feeds on 213K+ log lines. First encounter with a database timeout: agent reasons through the error chain (5-7 LLM iterations, ~$0.05). Produces a reusable error signature that crystallizes into a deterministic matching rule. Second encounter: instant recognition, zero AI cost, 500x cheaper. By month two, 80% of errors are handled deterministically.

25-Cycle Self-Improving Training Loop

Reads its own execution logs → identifies failures → proposes code fixes via Claude Code → applies patches → rebuilds → tests → loops back. 25 complete cycles, 6 hours, zero human intervention. By cycle 15, the agent was avoiding mistakes from cycle 3 without being told — it read its own history and adjusted. Cost per cycle decreased as context accumulated.

Developer Net

12 transitions across 6 zones. Takes a plain English feature spec → plans (LLM) → implements (Claude Code command) → tests (command) → reviews (agent with different model). Complete REST endpoint in under 4 minutes. Includes retry loops (up to 3 automatic retries) with failure context attached.

Intel Gather Platform

9 interconnected nets, 55 transitions, 35 shared places. Crawls websites, monitors forums, polls RSS, analyzes content, synthesizes knowledge, publishes reports. Adding a new data source = one place + one transition. Zero integration code. Shared places are the message bus.

Why Not LangChain, CrewAI, or Temporal?

The honest summary: if your agent runs a single prompt and returns a result, you don’t need AgenticNetsOS. If your agent needs persistent state, governed execution, audit trails, credential isolation, cost optimization, and distributed execution behind firewalls — you need something like this.

Getting Started in 5 Minutes

# Start the runtime
docker-compose up -d

# Open the CLI
agenticos chat

# Describe what you want
You: Create a monitoring pipeline that watches logs
     and creates alerts for critical errors.

# The system builds it. Watch it in the GUI at localhost:4200.
# Control it from Telegram. Stop it anytime.

Five minutes from Docker Compose to running agents. Everything created by prompting. Everything visible in the GUI. Everything traceable. Everything stoppable with one command.

Live Demo: Building a Log Analysis Pipeline via Chat

Everything described above might sound theoretical. So let me show you a concrete example that was built, deployed, and executed entirely through a chat conversation — in minutes, not hours.

The Challenge

Build a log analysis pipeline: take a natural language question like “Count how many ERROR lines we have”, turn it into the right shell command, execute it on a remote machine, and return the result. A classic use case that typically requires writing code, configuring infrastructure, and stitching services together.

With AgenticNetsOS, the entire thing was built through conversation with a coordinator agent powered by DeepSeek V3.1 (671B) running locally via Ollama.

What the Agent Built

The coordinator — an agent with rwxhl capabilities — designed and built this net in a single chat session:

Four places, two transitions, five arcs. The agent transition reads a natural language question plus an example CommandToken (which teaches it the expected output format), reasons about the right shell command, and produces a properly-structured token. The command transition picks it up via the executor and runs it.

Step by Step: What the Coordinator Did

• Cleaned the canvas — Deleted all existing elements (arcs first, then transitions, then places)
• Built the structure — Created all places and transitions with visual positioning, connected them with arcs, created runtime containers
• Configured inscriptions — Set the agent transition’s presets (prompt + example), postsets, and action. Set the command transition’s ArcQL query, executor dispatch, and output routing
• Deployed and started — Agent transition deployed to master, command transition assigned to executor, both started in the polling loop
• Tested end-to-end — Dropped a prompt token, watched the pipeline execute, queried results

31 tool calls across 23 iterations. The coordinator used CREATE_PLACE, CREATE_TRANSITION, CREATE_ARC, SET_INSCRIPTION, DEPLOY_TRANSITION, START_TRANSITION, CREATE_TOKEN, QUERY_TOKENS, and QUERY_EVENTS — all autonomously, all in a single conversation.

The Results

Query 1: “Count how many ERROR lines we have.”

The agent generated: grep -c 'ERROR' /private/tmp/agentic-net-master.log
Result: 546 ERROR lines. Execution time: 199ms.

Query 2: “Find the first error line and get the line as result.”

The agent generated: grep -i -m 1 'error' /private/tmp/agentic-net-master.log
Result: A Netty DNS resolver warning from startup — the very first error in the log. Execution time: 14ms.

Why This Example Matters

This demo shows every core concept in action:

• Everything by prompting — The user never wrote a shell command. Never touched a config file. Never wrote code.
• Agent transitions as the bridge — Natural language in, structured execution out. The agent transition is the intelligence layer between human intent and deterministic execution.
• Credential isolation — The command execution ran on a remote executor. The agent never saw how the executor authenticated or where the logs physically lived.
• Full observability — With the l (logs) capability, the coordinator used QUERY_EVENTS to inspect the event trail in real time — token consumption, transition firings, execution results.
• The crystallization path — Today, “Count X in the log” triggers an LLM call every time. But the pattern always produces grep -c 'X' <file>. That pattern can crystallize into a deterministic MAP transition — same result, zero AI cost, forever.

The full demo is available on YouTube — watch the coordinator build, deploy, and execute the pipeline in real time.

The Era of Naked Agents Is Ending

Organizations will demand the same governance for AI agents that they demand for every other system touching production data. Credential isolation. Audit trails. Cost control. Operational management. Traceability. These are table stakes for enterprise deployment — and they must be architectural properties, not afterthoughts.

AgenticNetsOS is the first runtime that provides all of them. Every agent governed. Every action traceable. Every credential isolated. Every cost measured. Everything created by prompting. Everything stoppable with one click.

The agents don’t run naked anymore. They run inside a runtime built for exactly this purpose.

AgenticNetsOS was built by one developer orchestrating AI coding agents over nine months. 182,000+ lines of code across 10 services. The system that governs agents was itself built with the help of agents.

Related articles: From Human-in-the-Loop to Living Automation • Executors and Deployment Architecture