What if AI agents didn’t just execute tasks—but designed and constructed the systems they need to complete them? And what if every capability they have—calling APIs, running shell commands, installing software on remote machines—was channeled through secure, auditable pathways that you configure? AgenticOS makes both possible.
The Breakthrough: Agents That Build, Not Just Execute
Traditional AI agents have a fundamental limitation: they can reason about problems, but they depend on humans to build the infrastructure that executes solutions.
An agent might conclude “I need to call this API every hour and alert if response times spike”—but it can’t actually create that monitoring system. A human has to translate that insight into code, deploy it, connect it to alerting services, and maintain it over time.
AgenticOS changes this equation entirely.
In AgenticOS, autonomous agents don’t just recommend what should happen—they directly create the structures that make it happen. When an agent needs an HTTP endpoint to fetch data, it creates an HTTP transition. When it needs to store intermediate results, it creates places. When it needs to route tokens based on conditions, it creates the arcs that define that flow.
Here’s what that looks like in practice:
This screenshot captures the core achievement: an AI agent that creates executable agentic process infrastructure autonomously. The agent on the left read a task token (“investigate the WordPress blog”), reasoned about what HTTP transitions it needed, created the entire right-side agentic process—places, transitions, arcs, inscriptions—deployed it, executed it via FIRE_ONCE, and stored the results. The Agent Memory place shows 6 tokens: patterns the agent learned and stored for future reuse.
But here’s what makes this genuinely powerful and safe: every agent transition runs with a specific security role that determines exactly which tools it can use. Through HTTP transitions, agents can call any API. Through COMMAND transitions, they can run any shell command on remote machines—even install software. The capability is unlimited. What makes it secure is that everything flows through operator-configured pathways: credential wallets, command allowlists, and per-transition role enforcement.
This is what we call Secure Agentic-Nets.
[table id=1 /]
Traditional AI Agent:
- Agent analyzes problem
- Agent generates recommendation
- Human builds the solution (code, deploy, maintain)
- Solution executes
- Agent analyzes next problem…
Agent is limited to reasoning. Human is bottleneck for execution. Knowledge dies with the conversation. Cost: $X per problem (forever).
Autonomous Structure-Building Agent:
- Agent analyzes problem
- Agent CREATES transitions, places, arcs
- Human reviews and deploys (or agent self-deploys)
- Structure executes continuously
- Agent reuses structure for similar problems
Agent builds persistent infrastructure. The role on each agent transition determines the trust level: read-only, design, or full autonomy. Knowledge persists as executable structure. Cost: $X first time, then $0 (structure runs).
Secure Agentic-Nets: Roles for Agent Transitions
This is the most important architectural decision in AgenticOS: every agent transition has a security role that defines what it’s allowed to do.
In a Petri net, a transition is the thing that fires—it reads tokens from input places, does something, and writes tokens to output places. An agent transition is a transition where the “doing something” is handled by an LLM. The agent reads its input tokens, reasons about the task, and uses tools to accomplish it.
The role assigned to that agent transition controls which tools the agent can use. Think of it like user permissions on a server. A read-only user can browse files. A developer can also edit code. An admin can also deploy. Same system, same capabilities—different users get different access.
Four permission flags define what an agent transition is allowed to do:
R (Read) – Query tokens, inspect places, browse the net W (Write) – Create and modify tokens, places, transitions, arcs, inscriptions X (Execute) – Deploy, start, stop, and fire transitions H (HTTP) – Make external HTTP calls through the credential proxy
You combine them into a short role string and assign it to the agent transition’s inscription:
{
"id": "t-analyze-code",
"kind": "agent",
"action": {
"type": "agent",
"nl": "@input.data.instruction",
"role": "rw" ← This agent can read and write, nothing else
}
}
That’s it. Two characters. The agent transition t-analyze-code can read data and create structures, but it cannot deploy anything, cannot fire other transitions, and cannot make HTTP calls.
Here are the most common role combinations:
r--- Observer (8 tools)
Query tokens, inspect places, browse structures.
Cannot change anything. Good for monitoring agents.
rw-- Builder (16 tools)
+ Create/delete tokens, design nets, write inscriptions.
Cannot deploy, execute, or call external APIs.
Good for designer agents that create agentic processes for human review.
rwx- Operator (20 tools)
+ Deploy transitions, start/stop them, fire them on-demand.
Cannot make external HTTP calls.
Good for deployment and lifecycle management agents.
rwxh Full Autonomy (21 tools)
+ External HTTP calls through the credential proxy.
Can do everything. Good for trusted automation agents.
rw-h Researcher (17 tools)
Can design agentic processes AND call external APIs for research,
but cannot deploy or execute anything.
Good for agents that gather data and propose agentic processes.
The role is enforced at runtime and cannot be escalated. If an agent transition with role rw-- tries to call DEPLOY_TRANSITION, the system blocks it immediately:
Agent (rw--) attempts: DEPLOY_TRANSITION t-fetch-api System response: "Tool 'DEPLOY_TRANSITION' is not allowed for your role (rw--). Available tools: QUERY_TOKENS, CREATE_TOKEN, DELETE_TOKEN, CREATE_NET, CREATE_PLACE, CREATE_TRANSITION, CREATE_ARC, SET_INSCRIPTION, EMIT_MEMORY, LIST_ALL_SESSIONS, ... Please choose a different tool or call DONE/FAIL."
The tool is never executed. The agent is told what it can do. This is fail-secure by design—an agent transition cannot break out of its assigned role.
The Credential Wallet
Here’s a subtlety that matters enormously for security: API keys and secrets are never stored in inscriptions and never visible to agents.
When an agent creates an HTTP transition that calls an external API, the inscription references credentials by name:
{
"type": "http",
"method": "POST",
"url": "https://api.openai.com/v1/chat/completions",
"headers": {
"Authorization": "Bearer ${credentials.OPENAI_KEY}",
"Content-Type": "application/json"
}
}
The agent writes ${credentials.OPENAI_KEY}. It never sees the actual key. The credential wallet is managed by the operator—when the executor processes the HTTP call, it resolves the credential reference and injects the real value into the outgoing request header.
Four authentication types are supported:
- Basic Auth — username:password base64-encoded
- Bearer Token — injected as Authorization header
- API Key — injected as header or query parameter
- OAuth2 Client Credentials — automatic token caching and refresh
This means: even an rwxh agent with full autonomy never sees the actual API key. It references credentials by name. The executor resolves them. The agent proposes which credential to use. The operator controls what that credential actually contains.
Command Allowlisting on Executor Hosts
COMMAND transitions are where the real power lives. Through them, agents can execute any shell command on any remote machine that has a AgenticOS executor installed. Install software. Query databases. Run analysis scripts. Deploy containers. The capability is unlimited—but the control is precise.
Each executor host defines a fine-grained allowlist of permitted commands. The agent proposes a command; the executor checks it against the allowlist before running anything.
Process isolation is enforced at every level:
- Each command runs in its own isolated process
- Configurable timeout per command (default 60s, max 10 minutes)
- Working directory sandboxing
- Environment variable injection (controlled by operator)
- Serialized execution—no parallel command storms
The executor is pull-based: it polls the master for work every 2 seconds. No inbound ports need to be opened. This means executors can sit inside firewalled networks, air-gapped environments, or on customer premises—and still receive work securely.
The critical design principle: operators control what can run on their machines. An agent might propose apt-get install python3-pandas on a data analysis server—and the allowlist can permit exactly that while blocking rm, sudo, or ssh. The capability is there. The guardrails are operator-defined.
Example allowlist on a data-analysis executor: ✅ curl, jq, python3, pip install (specific packages) ✅ apt-get install python3-pandas ❌ rm, sudo, ssh, chmod, dd
Two Patterns, One Architecture
The role system enables two fundamentally different operational patterns:
Pattern 1: The Designer Agent (Human-in-the-Loop)
Agent transition role: rw-h or rw--
User: "I need an agentic process to monitor our support inbox and escalate urgent tickets" Designer Agent Transition (rw--): ├─ Analyzes requirements ├─ CREATES complete agentic process: │ ├─ p-inbox, p-categorized, p-team-eng, p-team-billing, p-urgent │ ├─ t-fetch-tickets (HTTP), t-categorize (Agent), t-route (Pass) │ └─ All connecting arcs + inscriptions ├─ Stores pattern in memory for reuse └─ STOPS. Cannot deploy. Waits for human. Human reviews in GUI: ├─ Sees complete process diagram ├─ Inspects each transition's inscription ├─ Modifies configurations (URLs, schedules, timeouts) ├─ Binds credentials from wallet ├─ Deploys selectively (maybe only 3 of 5 transitions) └─ Starts the deployed transitions
Security benefit: The agent cannot “go rogue.” Even if the LLM hallucinates a destructive command, it physically cannot execute it. The created structures are inert data until a human activates them.
Pattern 2: The Autonomous Agent (Full Self-Governance)
Agent transition role: rwxh
User: "Analyze our WordPress site for SEO issues" Autonomous Agent Transition (rwxh): ├─ Creates HTTP transition: t-fetch-pages ├─ DEPLOYS it to executor ├─ FIRES it → gets pages from WordPress API ├─ Creates COMMAND transition: t-extract-meta ├─ DEPLOYS and FIRES → runs jq to extract meta tags ├─ Analyzes results using its own LLM reasoning ├─ Stores findings as tokens in p-seo-report ├─ Creates PNML visualization for the GUI └─ All done. No human needed.
Use case: Trusted environments where speed matters more than approval gates. Development agentic processes, internal tooling, personal automation.
Goal-Driven Automation: From Natural Language to Running Systems
Both patterns share the same starting point: a human describes a goal in natural language.
Step 1: The Agent Understands the Goal
Goal: "Monitor our WordPress site for SEO issues" Agent reasoning: ├─ I need to periodically fetch pages from the WordPress API ├─ I need to analyze page content for SEO quality ├─ I need to generate recommendations ├─ I need to store results somewhere accessible └─ I need all this to run WITHOUT me being invoked each time
Step 2: The Agent Designs and Creates
The agent uses structure creation tools to directly build the agentic process:
Agent CREATES: ├─ CREATE_NET: "WordPress SEO Monitor" ├─ CREATE_PLACE: p-wp-pages (URLs to scan) ├─ CREATE_PLACE: p-page-content (fetched pages) ├─ CREATE_PLACE: p-seo-report (analysis results) ├─ CREATE_TRANSITION: t-fetch-pages (HTTP transition) ├─ CREATE_TRANSITION: t-analyze-seo (Agent transition) ├─ CREATE_ARC: p-wp-pages → t-fetch-pages ├─ CREATE_ARC: t-fetch-pages → p-page-content ├─ CREATE_ARC: p-page-content → t-analyze-seo ├─ CREATE_ARC: t-analyze-seo → p-seo-report ├─ SET_INSCRIPTION: t-fetch-pages with HTTP config └─ SET_INSCRIPTION: t-analyze-seo with analysis prompt
Step 3: What Happens Next Depends on the Role
If rw-- (Builder):
Agent: "I've created the complete agentic process. I cannot deploy it.
Awaiting human review."
Human reviews → binds credentials → deploys selectively → starts
If rwxh (Full Autonomy):
Agent: "I've created the agentic process. Deploying t-fetch-pages now.
Firing... got 47 pages. Creating analysis transition.
Deploying t-analyze-seo. Firing... analysis complete.
Results stored in p-seo-report."
Everything done in one session. No human involvement.
Same intelligence. Same design capabilities. Different role on the agent transition.
What Agents Can Actually Do
AgenticOS agents can do anything. That’s the point. The architecture doesn’t limit capability—it ensures every capability flows through a secure, auditable pathway.
HTTP Transitions: Calling Any API
With the h flag, agents can create and fire HTTP transitions that call any endpoint on the internet. Every request goes through the credential proxy—the agent writes templates, the executor resolves secrets:
{
"type": "http",
"method": "POST",
"url": "https://api.openai.com/v1/chat/completions",
"headers": {
"Authorization": "Bearer ${credentials.OPENAI_KEY}",
"Content-Type": "application/json"
},
"body": {
"model": "gpt-4",
"messages": [{"role": "user", "content": "${input.data.prompt}"}]
}
}
COMMAND Transitions: Shell Access on Remote Machines
Through COMMAND transitions deployed to remote executors, agents can run shell commands on any machine that has a AgenticOS executor installed:
# On a remote production server kubectl get pods -n production docker stats --no-stream # On a data analysis machine pip install pandas scikit-learn python3 analyze_data.py --input /data/latest.csv # On a development machine npm test -- --coverage git log --oneline -10 # On any machine with an executor claude -p "Analyze this code" --no-session-persistence < /dev/null
The capability is unlimited. An agent could create a COMMAND transition that installs software, configures a service, or queries a production database—if the executor's allowlist permits it. The operator defines what's allowed per machine. The agent proposes. The executor enforces.
Chaining It All Together
An autonomous agent transition (rwxh) can chain HTTP and COMMAND transitions into a pipeline that:
- Fetches data via HTTP from an external API
- Processes it via shell commands on a remote machine
- Stores results in the net's places
- Triggers alerts via HTTP to Slack/Discord
- Runs continuously without any human intervention
A builder agent transition (rw--) can create this exact same pipeline—every place, every transition, every inscription, every arc. But it physically cannot deploy or execute any of it. The human must activate each piece.
The "Want" Token Pattern: Self-Aware Designer Agents
Designer agents face an interesting challenge: they can create structures but cannot execute them. How do they track what they've built and what they're waiting for?
Through "want" tokens—a self-tracking pattern where the agent writes tokens to its own input place:
{
"want": "t-fetch-pages",
"expecting": "tokens in p-page-content",
"reason": "Need fetched pages to analyze for SEO",
"status": "awaiting-deployment",
"created_at": "2026-02-04T10:00:00Z"
}
The Self-Aware Loop
Execution #1 (Designer Agent): ├─ Agent reads p-want: empty ├─ Agent reads task: "Monitor SEO" ├─ Agent CREATES: t-fetch-pages, p-page-content ├─ Agent WRITES want token: "waiting for t-fetch-pages to be deployed" ├─ Agent exits → human sees new structures in GUI Human deploys t-fetch-pages with credentials Execution #2: ├─ Agent reads p-want: "want t-fetch-pages → p-page-content" ├─ Agent checks p-page-content: Has data! (human deployed it) ├─ Agent uses the data for analysis ├─ Agent creates next structure (t-analyze-seo) └─ Agent writes new want token for t-analyze-seo
The agent knows what it asked for and checks if it got it. No external memory needed—the net IS the memory.
Nets That Run While You Sleep
Once deployed—whether by human or by autonomous agent—the agentic process runs continuously without any AI involvement.
Example: Personal Calendar Assistant
Places: ├─ p-calendar-events (upcoming meetings) ├─ p-conflicts (detected scheduling conflicts) ├─ p-proposals (suggested changes) └─ p-notifications (alerts for your attention) Transitions: ├─ t-sync-calendar (kind: http, fetches from Google Calendar API) ├─ t-detect-conflicts (kind: map, finds overlapping meetings) ├─ t-suggest-reschedule (kind: agent, proposes alternatives) └─ t-morning-briefing (kind: agent, generates daily summary)
What happens overnight:
11:00pm: New meeting request arrives via email
11:30pm: t-sync-calendar fires, updates p-calendar-events
11:31pm: t-detect-conflicts fires, finds overlap
11:32pm: t-suggest-reschedule fires, creates proposal token
7:00am: t-morning-briefing fires
Generates: "2 conflicts detected. 1 proposal pending."
7:15am: You wake up, review proposals in GUI, approve with one click
Everything that happened overnight is captured as events. Full audit trail. No AI cost overnight—just structure executing.
Petri Nets That Create Petri Nets
The ultimate expression of this architecture: agent transitions that design and build other agentic processes.
A single conversation with an rw-- agent transition produces a complete, ready-to-deploy agentic process:
User: "Build a support ticket pipeline with categorization and escalation" Agent Transition (rw--): ├─ Creates 5 places: inbox, categorized, engineering, billing, urgent ├─ Creates 4 transitions: fetch, categorize, route, escalate ├─ Creates 8 arcs connecting everything ├─ Writes 4 inscriptions (HTTP, Agent, Pass, Pass) ├─ Creates PNML visualization with proper layout ├─ Stores pattern in memory: "support-ticket-pipeline" └─ Awaits human deployment
The same request to an rwxh agent transition goes further:
Agent Transition (rwxh): ├─ Same creation steps ├─ DEPLOYS all 4 transitions ├─ FIRES t-fetch to test the pipeline ├─ Verifies results flow through correctly └─ Agentic Process is live and running
The Self-Improving System
Over time, the agent:
- Accumulates patterns from successful agentic processes in its memory place
- Recognizes similar requests ("this is like the last support agentic process")
- Reuses and adapts existing structures instead of building from scratch
- Learns from failures (captures pitfalls as learned-pattern tokens)
Each task makes the system more capable. The agent gets better at designing agentic processes the more it designs—regardless of its role.
The Full Picture: Autonomous SaaS Operations
Everything above—designer agents, autonomous agents, HTTP transitions, COMMAND transitions, credential wallets, executor allowlists—comes together when you build a large-scale system where multiple agent transitions with different roles manage an entire operation.
Imagine running a SaaS product. Today you have a team of people handling customer support, deployments, monitoring, incident response, billing, and analytics. With Secure Agentic-Nets, you can build a single Petri net where specialized agent transitions handle each domain—each with exactly the permissions it needs, each producing work for the others, the whole thing running continuously.
Here's what that looks like:
┌─────────────────────────────────────────────────────────────┐ │ AUTONOMOUS SAAS OPERATIONS NET │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ p-tickets │───→│ t-triage │───→│ p-triaged │ │ │ │ (incoming) │ │ role: rw-h │ │ │ │ │ └──────────────┘ └──────────────┘ └──────┬───────┘ │ │ │ │ │ ┌──────────────────────┤ │ │ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ t-auto-fix │ │ t-escalate │ │ │ │ role: rwxh │ │ role: rw-h │ │ │ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ p-resolved │ │ p-human-attn │ │ │ └──────────────┘ └──────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ p-git-events │───→│ t-ci-runner │───→│ p-build-ok │ │ │ │ (webhooks) │ │ role: rwxh │ │ │──┐│ │ └──────────────┘ └──────────────┘ └──────────────┘ ││ │ │ ││ │ ▼ ││ │ ┌────────────┐ ││ │ │ t-deploy │ ││ │ │ role: rwxh │ ││ │ └─────┬──────┘ ││ │ │ ││ │ ▼ ││ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ││ │ │ p-metrics │◄───│ t-monitor │◄───│ p-deployed │ ││ │ │ │ │ role: r--- │ │ │◄─┘│ │ └──────┬───────┘ └──────────────┘ └──────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ t-alert │───→│ p-incidents │ │ │ │ role: rw-h │ │ │───→ (back to t-triage)│ │ └──────────────┘ └──────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ p-usage-data │───→│ t-billing │───→│ p-invoices │ │ │ │ │ │ role: rw-h │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────────────┘
Six agent transitions, four different roles, one interconnected net:
t-triage (role: rw-h) "Reads incoming support tickets, calls our knowledge base API to classify them, routes fixable issues to t-auto-fix and complex ones to t-escalate." ✅ Can read tickets, write classifications, call external APIs ❌ Cannot deploy or fire anything t-auto-fix (role: rwxh) "For known issues (password resets, config errors, quota bumps): creates a COMMAND transition, deploys it, fires it against the customer's environment, verifies the fix, responds to the customer." ✅ Full autonomy — can create, deploy, execute, call APIs Allowlist on customer executor: reset-password, update-config, bump-quota t-escalate (role: rw-h) "For complex issues: enriches the ticket with system diagnostics via API calls, writes a detailed summary, creates a structured handoff token for the human support team." ✅ Can read, write, call APIs for diagnostics ❌ Cannot deploy or execute — humans handle complex cases t-ci-runner (role: rwxh) "Triggered by git push webhooks. Creates COMMAND transitions to run the test suite on the build server, collects results. If tests pass, creates a deploy-ready token." ✅ Full autonomy on the build server Allowlist on build executor: git, npm, pytest, docker build t-deploy (role: rwxh) "Takes deploy-ready tokens and rolls out to production. Creates COMMAND transitions for blue-green deployment, runs health checks, rolls back if checks fail." ✅ Full autonomy on the production executor Allowlist on prod executor: kubectl, docker, health-check scripts ❌ No rm, no sudo, no ssh — only approved deployment commands t-monitor (role: r---) "Continuously queries production metrics from p-deployed. Read-only — it can observe everything but change nothing. When it detects anomalies, it writes alert tokens to p-metrics." ✅ Can read all net state ❌ Cannot modify anything — pure observation Wait — if it's r---, how does it write alert tokens? It doesn't. The anomaly detection is a MAP transition that reads p-deployed metrics and emits to p-metrics. t-monitor is the agent that reads those metrics and adds analysis context. The alert itself is a separate rw-- agent transition (t-alert). t-alert (role: rw-h) "Reads anomaly tokens, calls PagerDuty/Slack APIs to notify the team, writes structured incident tokens back into p-incidents — which feed right back into t-triage." ✅ Can read, write, call notification APIs ❌ Cannot deploy or execute — it raises alarms, doesn't fix things t-billing (role: rw-h) "Reads usage data, calls Stripe API to generate invoices, writes invoice tokens for the finance team to review." ✅ Can read usage, write invoices, call Stripe API ❌ Cannot deploy or execute anything
Look at what's happening here:
Every agent transition has exactly the permissions it needs—no more. The monitoring agent can't accidentally deploy code. The billing agent can't run shell commands. The auto-fix agent has full autonomy but only on specific executor hosts with specific allowlists. The CI runner can build and test but can't access production.
And the whole thing is one Petri net. Tokens flow from support tickets through triage to resolution. Git pushes flow through CI to deployment. Metrics flow through monitoring to alerting. Incidents loop back to triage. It's a complete, self-sustaining operational system where each agent transition handles its domain with exactly the right level of trust.
This is what traditional systems achieve with hundreds of microservices, RBAC policies, CI/CD pipelines, monitoring stacks, and incident runbooks—all maintained by a team of engineers. With Secure Agentic-Nets, it's one net, multiple agent transitions, each with a two-to-four-character role string.
Why Secure Agentic-Nets Work
Let's be explicit about the security model. The point is not that agents are limited—they're not. An rwxh agent transition can call any API on the internet, run any shell command on remote machines, install software, query databases, and chain all of this into continuously running pipelines. The capability is real and unlimited.
What makes it secure:
- Per-transition roles. Each agent transition has its own role. A monitoring agent (
r---) and a deployment agent (rwxh) can exist in the same net with completely different permissions. The role is set in the inscription and cannot be changed at runtime. - Credential isolation. Agents reference credentials by name (
${credentials.STRIPE_KEY}). The executor resolves them. The agent never sees the actual secret. - Command allowlists. Each executor host defines what commands are permitted. An agent can propose
apt-get install python3-pandas—the allowlist decides if it runs. Operators control their machines. - No privilege escalation. An agent transition cannot modify its own inscription. It cannot change its role. It cannot grant itself new tools.
- No cross-agent access. Each agent session has its own memory scope. Agent A cannot read Agent B's memory, tokens, or session state.
- Pull-based execution. Executors poll for work. No inbound ports. Executors can sit inside firewalled networks and still operate securely.
- Full audit trail. Every tool call, every token flow, every transition firing is logged with the agent's role and identity.
The Achievement: Controlled Power at Every Level
What AgenticOS achieves is something that didn't exist before: AI agents that can build complete, executable agentic process infrastructure—with every capability flowing through secure, operator-configured pathways.
| Aspect | Builder Agent (rw--) | Autonomous Agent (rwxh) |
|---|---|---|
| Design agentic processes | Yes | Yes |
| Create structures | Yes | Yes |
| Deploy transitions | No — human must deploy | Yes — self-deploys |
| Call any API | No — creates, human fires | Yes — through credential proxy |
| Run any shell command | No — creates, human runs | Yes — through executor allowlist |
| Install software remotely | No — proposes, human executes | Yes — if allowlist permits |
| Start/stop agentic processes | No — human controls | Yes — full lifecycle |
| See credentials | Never — reference by name | Never — reference by name |
| Security model | Capability through human gate | Capability through secure channels |
| Use case | Production, compliance | Dev, internal, trusted |
The Self-Supporting Loop
The most remarkable property: the system supports itself.
- Agent encounters problem → Creates structure to solve it
- Structure gets deployed → By human (builder) or self (autonomous)
- Structure runs → Produces results continuously
- Agent learns → Stores pattern in memory
- Similar problem arrives → Agent reuses structure (no rebuild)
- Structure library grows → System becomes more capable over time
Each task makes the system better. Each agentic process adds to the library. Each pattern captured means future tasks are faster and cheaper.
You assign the roles. The architecture enforces them.
The Bigger Picture
AgenticOS doesn't force a choice between safety and capability. It gives you both—through Secure Agentic-Nets:
- Start safe: Use
r---agent transitions for monitoring and observation - Add design power: Upgrade to
rw--for agents that build agentic processes - Open HTTP access: Use
rw-hfor agents that research via external APIs - Enable execution: Use
rwx-for deployment without external calls - Go autonomous: Use
rwxhwhen you trust the environment and need speed
You can run all role levels simultaneously in the same net. A read-only agent transition monitors your production system. A builder agent transition creates new agentic processes for review. An autonomous agent transition handles deployment—running commands on production servers, calling APIs, managing the full lifecycle. Each does exactly what its role permits. The SaaS operations example above shows how this scales: six agent transitions, four different roles, one net that runs an entire operation.
This isn't AI automation with an on/off switch. It's AI automation with a volume dial per agent transition—and you control exactly where each one is set.
Built with AgenticOS Secure Agentic-Nets—the platform where autonomous agents build their own infrastructure, with every capability flowing through secure, operator-configured pathways.
February 2026