Vision · v0.9 → v1.0
What if agents were
a language feature?
Today's agent stacks bolt tools, prompts, and memory onto Python with decorators and dictionaries — nothing checks them. Astra's endgame is to make these first-class, typechecked constructs of the language itself.
ThesisThe division of labor is changing
Every previous language generation optimized for a human at a keyboard. The next one has three participants with different strengths:
| Participant | Contributes | Needs from the language |
|---|---|---|
| The agent | Tactical speed — code at machine pace | A generable surface + machine-readable feedback |
| The compiler | Strategic structure — enforced design | Types, contracts, deterministic builds baked in |
| The human | Judgment — intent and review | Code where the compiler already ruled out the mundane bugs |
Astra is designed around that triangle. Each release strengthens the strategic layer another notch:
| Release | Strategic guarantee it adds |
|---|---|
| v0.6–0.7 shipped | Types, Result, machine-readable diagnostics, explicit dyn, reproducible locks |
| v0.8 shipped | One true LLVM-IR backend — the foundation every future target builds on |
| v0.9 shipped | A sound core: nominal types, payload enums, ? error handling, ARC memory reclamation, a compiler that never panics — delivered as cross-platform binaries |
| Next | Tool schemas, agent state, prompts, and delegation — all typechecked; generated code sandboxed in WASM |
| v1.0 | One strategic layer across native, WASM, and GPU targets |
Delivery against each guarantee is scored on the progress tracker — currently 5 of 11 shipped, each backed by a passing test.
AheadAgent-native keywords
Four keywords are reserved and ratified (Bet 4). The design intent — syntax is illustrative and will evolve through an RFC process:
tool search_flights(from: str, to: str, date: str) -> Result<[Flight], ApiError> {
// a tool is a typed, sandboxed capability;
// its signature IS its schema — no JSON-schema drift
}
memory TripContext {
budget: float,
preferences: [str] // typed, persistent agent state
}
agent TravelPlanner {
tools: [search_flights],
memory: TripContext,
prompt plan = "Find flights within ${memory.budget}";
}What the compiler can then guarantee — before anything runs:
- Tool contracts hold. A tool's parameter and return types are checked at every call site. The "function-calling schema" cannot drift from the implementation because they are the same thing.
- Memory is typed. Agent state isn't a dict of anything — reads and writes typecheck like struct access.
- Prompts are checked templates. A
promptinterpolation referencing a missing memory field is a compile error, not a silent hallucination input. - Subagent boundaries are contracts. An agent handing work to another agent is a typed call — the compiler verifies the whole delegation graph.
Alongside the keywords: an agent SDK (bindings for LLM providers) and a sandbox so tools execute with declared capabilities only.
Enabling layerWhat has to land first
The same LLVM backend emits WebAssembly — verified agent code running in a capability-scoped sandbox, plus a browser playground for this site.
Astra won't pretend NumPy and PyTorch don't exist. A typed boundary calls into the Python ecosystem where it's strong, keeps the orchestration layer verified.
Language server and formatter — for the humans reviewing what agents wrote.
async/await already parses and compiles (synchronous lowering); a real task runtime and a standard library form under ARC memory management.
v1.0 completes the arc
- GPU target (NVPTX) — the third LLVM target: same language from orchestration script to kernel.
- Mifa registry (mifa.dev) — checksummed, signed packages; the lockfile contract goes global.
- Production tooling — test/bench runners, docs generator, debugger support.
PositioningAstra vs. the alternatives for agent code
Every language in this table is excellent at what it was designed for. The comparison is scoped to one question: what should an agent generate?
| Python | Rust | Go | Mojo | Astra | |
|---|---|---|---|---|---|
| Mistakes caught before run | Few (runtime) | Most | Many | Most | Most — by design goal |
| Diagnostics as machine-readable contract | No | Partial (--message-format=json, rich but complex) | Partial | No | Yes — stable codes + suggestions, primary interface |
| Easy for an LLM to generate correctly | Yes | Hard (lifetimes) | Yes | Moderate | Yes — Python-like surface, no borrow checker |
| Native performance | No | Yes | Yes | Yes | Yes (LLVM) |
| Agent primitives in the language | Frameworks only | Frameworks only | Frameworks only | No | Planned as keywords |
| Memory model burden on the generator | None (GC) | High (ownership) | None (GC) | Low | None visible (ARC) |
| Maturity today | Production | Production | Production | Early | Alpha — tracked honestly |
The bet in one sentence: Rust-grade verification with Python-grade generability, plus agent concepts the compiler itself understands. No incumbent occupies that intersection — and the maturity row is exactly why this roadmap exists.
LockedThe five bets underneath
The vision isn't a mood board — it rests on five architecture decisions debated and ratified on 2026-07-02, each with recorded rationale, accepted costs, and first milestones (two of which have already shipped):
| Bet | Decision | First milestone |
|---|---|---|
| 1 — Memory | ARC + escape analysis + region | reclaiming since v0.9 (partial) |
| 2 — Typing | Static by default, gradual via dyn | shipped v0.7 |
| 3 — Backend | One LLVM compiler → native / WASM / GPU | native shipped v0.8 · WASM planned |
| 4 — AI primitives | tool/agent/prompt/memory keywords | planned |
| 5 — Interop | Embedded CPython in stdlib | planned |
The full decision records — rationale, accepted costs, amendment process — live in the repository and publish with the source at v1.0-beta.