- 1. Why a New Language?
- 2. Why Harvard Architecture?
- 3. Why Elixir/BEAM Influence?
- 4. Why Chapel Influence?
- 5. Why Linear Types (Ephapax Influence)?
- 6. Why Session Types?
- 7. Why Choreographic Compilation?
- 8. Why Content-Addressable Behaviour?
- 9. Why Capability-Based Security?
- 10. Dual-Use Considerations
Every existing "agent framework" (LangChain, CrewAI, AutoGen, etc.) is a library in an existing language. This means agent safety properties are enforced by convention, documentation, and runtime checks — all of which can be bypassed, forgotten, or misconfigured.
007 takes a different approach: safety properties are enforced by the grammar. A program that violates agent safety invariants does not parse. This is the difference between "please don’t concatenate user input into SQL" and "the language has parameterised queries and no string concatenation operator in query context."
When Agent A creates Agent B, it passes:
-
Data: knowledge, context, parameters, prompts
-
Control: behaviour, tool use, decision logic
In every existing framework, these are the same type — strings, JSON objects, Python dicts. There is no grammatical distinction between "this is what the agent knows" and "this is what the agent does." This is structurally identical to SQL injection, XSS, and every other injection vulnerability.
Julia-the-Viper (JTV) proved that Harvard Architecture can be enforced
grammatically. JTV’s Data Language was addition-only, pure, and total — it
provably halts and cannot perform side effects. 007 generalizes the Data
Language to the full scalar arithmetic vocabulary (+ - * / %) while
preserving totality via a degenerate-case convention (division and modulo
by zero yield Unit). The Harvard invariant — that data expressions cannot
contain control flow — is unchanged by this generalization; adding
arithmetic operators does not introduce any way to embed control
statements in data context. Control flow exists only in the Control
Language.
007 applies this same principle to agent creation:
-
An agent’s data context (what it knows) is defined in the Data Language
-
An agent’s behaviour (what it does) is defined in the Control Language
-
The grammar prevents crossing the boundary
Result: an attacker who controls an agent’s data inputs cannot inject behaviour. It’s not a runtime check — it’s a parse error.
The BEAM virtual machine has 35+ years of production experience managing millions of concurrent, communicating, failing processes. This is exactly what an agent runtime needs:
-
Lightweight processes — spawn millions of agents without OS thread overhead
-
Supervision trees — every agent has a known owner with restart authority
-
Hot code swapping — update agent behaviour without stopping the system
-
Distribution — spread agents across machines transparently
-
Let it crash — agents fail gracefully; supervisors handle recovery
No other runtime offers all five. The BEAM is the natural target for 007.
Chapel introduces locale-aware parallelism — the programmer specifies not just what to compute but where to compute it. For agents, this maps to a critical question: does this agent run locally, on a GPU cluster, via a remote API, or at an edge node?
007 adopts Chapel’s locale concept to make agent placement explicit and type-checked.
Agent handles in most frameworks are plain references — they can be copied, shared, forgotten. This leads to:
-
Leaked agents — spawned but never collected
-
Duplicated messages — sent twice because the handle was copied
-
Zombie processes — agents that outlive their purpose
Ephapax’s linear types solve this: a linear handle must be consumed exactly once. The compiler rejects programs that drop or duplicate handles.
Agent communication in existing frameworks is untyped — agents send arbitrary messages and hope the receiver understands. Protocol violations are runtime errors (or worse, silent misbehaviour).
Session types make communication protocols part of the type system. The compiler verifies that both sides of a conversation follow the agreed protocol. Missing messages, wrong types, out-of-order sends — all are compile errors.
Writing individual agents and hoping they coordinate correctly is error-prone. Choreographic programming inverts this: write the global protocol once, and the compiler projects it to each participant’s local code.
This guarantees protocol compatibility by construction — if the choreography type-checks, the projected local code cannot violate the protocol.
Agent behaviour should be:
-
Immutable — what you tested is what runs
-
Auditable — you can inspect exactly what an agent will do
-
Reproducible — same hash = same behaviour, everywhere, always
-
Cacheable — behaviours can be shared and reused safely
Unison proved this works for general-purpose code. 007 applies it to agent definitions specifically.
The principle of least privilege is essential for agents. An agent that only needs to read files should not be able to write files, spawn other agents, or access the network.
Pony’s reference capabilities proved that this can be enforced at compile time via the type system. 007 adapts this for agent capabilities: permissions are phantom type parameters, and the compiler rejects agents that exceed their granted capabilities.
007 is voluntarily classified as dual-use technology. See DUAL-USE-NOTICE.adoc for details.
The author believes that the safety mechanisms built into 007 (Harvard architecture, capability security, linear handles, supervision) make it harder to build dangerous agent systems than existing frameworks, not easier. However, the novelty of the approach warrants caution.