aaspaiyour agent workforce, as code.
agent as service platform with agentic interop. Orchestrate Claude Code, Codex, Cursor, and OpenCode from a single git repo.
v0.1 · MIT-style for adoption, AGPL for service providers.
Modern teams want to delegate real work to AI agents.
A developer to write code, an operator to triage issues, a tester to run the suite. Each agent runs in its own agentic CLI (Claude Code, Codex, Cursor, OpenClaw…) and each CLI has its own way of being configured, scheduled, and observed.
The interesting question is not “can the agent solve this task?”— that is the CLI's problem. The interesting question is: who runs the orchestration around it?
Today most teams glue cron, shell scripts, and ad-hoc tools together. That glue does not version, does not audit, does not survive a team handover, and does not generalize from one agent to many.
Treat the agent workforce as configuration, not as code.
You write the agents, the knowledge they read, the tools they can call, and the loops that wake them as files in a git repository. The runtime reads those files, runs the agents, and writes back what happened to a database.
Your repository
versioned- agents/ — agent definitions
- knowledge/ — versioned memory
- loops/ — recurring work
- skills/ — reusable capabilities
- aaspai.config.ts
State
append-only rowsSessions, events, audit log, and budget live in the database — written by the runtime during a run.
If a human wrote it, it's a file.If the system wrote it during a run, it's a row.
Five design choices that shape everything.
Agents are roles, not models
An agent is a system prompt, a list of tools, a list of skills, and a scope of authority. The model that powers it is a property of the harness, not the agent.
Loops are the unit of recurring work
A loop is a markdown file with a gate, a budget, a schedule, and a session template. The scheduler wakes the loop, the gate decides whether to run, the budget caps it, the session runs the work.
Knowledge is long-term, versioned memory
Knowledge is stored in OKF files — markdown with typed YAML frontmatter. The agent's system prompt is built by indexing this knowledge at session start.
The harness is swappable
The same session can run against claude_local, codex_local, cursor_local, or a deterministic dry_run_local. Switch the harness in AGENT.md and the agent talks to a different model.
State is observable, not magical
Every session writes to session_events. Every gate decision writes to a ledger. The CLI can render any of it back as a markdown STATE file you can paste into a pull request.
The boundaries are deliberate.
Not a model — aaspai does not train or host a model. It orchestrates the agentic CLIs that do.
Not a chat product — aaspai is a runtime and an orchestration plane with an API and a CLI, no chat UI.
Not a hosted SaaS — aaspai is self-hosted. You run it on your machine, your CI, or your servers.
Built for teams who already live in the CLI.
Engineers
who want their agent workforce to be reviewable like any other piece of code.
Teams
already using Claude Code, Codex, or Cursor that want a shared substrate to coordinate them.
Builders
who want to dogfood their own agent platform to build the agent platform.
Anyone
who has outgrown cron + shell scripts and wants a real scheduler, audit log, and budget system.
Four layers, each depending only on the one below.
Orchestration
(deferred) parent agent (CEO) · workers · projects · tasks
Loops + sessions + skills + tools
loops library · unified execution surface · skill registry · tool registry · knowledge layer
Runtime / execution targets
local · docker · ssh · sandbox (e2b · daytona · cloudflare)
Adapters / harness
claude_local · codex_local · cursor · opencode_local · opencode_cli · openclaw · hermes · dry_run_local
Foundation
contracts · config · observability · identity · auth · audit · db · crypto · testing
The full source, docs, and roadmap live on GitHub.
Star the repo, open an issue, send a PR. aaspai is built in the open.