Agent Recipes, Artifacts, and Orchestrators

Calciforge should support more agent runtimes without pretending every upstream tool deserves first-class adapter maintenance. The working direction is a three-part vocabulary:

Working Now

Near-Term Work

First-Class Policy Wiring

Calciforge’s security promise should not depend on an agent runtime politely following prompt instructions. First-class agents need a path to submit structured action intent to Calciforge’s policy layer before the action runs. The policy should decide allow, review, or deny while preserving enough audit detail to explain the decision later.

The current target shape is:

OpenClaw is the first managed-agent path that should receive the full pattern: channel plugin, reply callbacks, native policy plugin, proxy configuration, health checks, and rollback behavior. Claude Code has a hook-based path. Codex should move toward ACP plus Calciforge-owned tools where possible. opencode should prefer ACP or a maintained plugin path once the interface is stable.

ZeroClaw needs an explicit product decision. The official release can remain a supported or best-effort adapter, but Calciforge should not inherit static upstream paranoia as the main policy contract if that blocks useful actions that Calciforge policy would otherwise allow. If upstream does not expose a blocking, configurable policy hook, a fork or library-mode integration may be justified. Reviving a name such as NonZeroClaw could make sense for that path: a ZeroClaw-compatible runtime whose policy authority is Calciforge/Clash, while official ZeroClaw remains the stricter compatibility option.

Each first-class agent should eventually have a short support matrix:

ACP Direction

ACP is the most promising common protocol layer for interactive coding agents. Calciforge already has kind = "acp" and kind = "acpx" paths, but Zed’s current ACP ecosystem suggests the higher-value product shape is:

That path fits both direct agents and orchestrators. Orchestrators such as AgentPool, cagent, or fast-agent can sit behind ACP and present one session surface to Calciforge while coordinating their own worker teams internally.

Codex ACP Smoke Notes

@zed-industries/codex-acp is a practical first smoke target for native ACP work. A local protocol smoke against version 0.12.0 initialized cleanly and advertised:

A raw session/list request returned an empty sessions array rather than an error. That means session discovery should not stay limited to the acpx adapter long term. The current native kind = "acp" implementation uses the pinned sacp schema, which supports session/load but does not expose the newer session/list capability in its typed API. The likely next step is to either update the ACP/SACP dependency or add a narrow raw JSON-RPC extension for session/list while keeping typed handling for initialize, session/new, session/load, and session/prompt.

Implementation direction:

Orchestrator Direction

Orchestrators need a control plane separate from normal chat adapters:

submit task -> receipt -> status/progress -> final outbound message

Gas Town is the motivating case. Calciforge should talk to the Mayor by default, discover available targets, submit or nudge work through normal Gas Town commands, relay progress, and deliver final summaries or artifacts. Direct crew or task-worker targeting should be discoverable and policy-gated rather than treated as ordinary chat routing.

The first repository examples model this as wrapper recipes rather than first-class adapters:

Useful orchestrator outputs may include:

Agent-Accessible Calciforge APIs

The artifact model should not be npcsh-specific. npcsh is only the first useful smoke because image generation naturally produces files. The broader contract should let an authorized agent or orchestrator ask Calciforge to create, ingest, validate, and deliver artifacts through the same channel envelope.

OpenClaw is the most important early target because it is a first-class managed agent path rather than a niche media CLI. The current openclaw-channel bridge sends text into OpenClaw and receives a correlated callback:

{ "sessionKey": "calciforge:primary-agent:operator", "message": "done" }

For diagrams, memes, screenshots, reports, or generated files, the callback can also include inline base64 attachments while Calciforge still owns the security boundary:

{
  "sessionKey": "calciforge:primary-agent:operator",
  "message": "I made a diagram.",
  "attachments": [
    {
      "mimeType": "image/png",
      "name": "diagram.png",
      "caption": "Generated diagram",
      "dataBase64": "..."
    }
  ]
}

Calciforge copies callback artifacts into a Calciforge-owned run directory, enforces type and size limits, and then delivers through Matrix, Telegram, SMS fallback, or any future channel. URL ingestion remains future work and needs its own SSRF-safe policy: allowed origins, no ambient credentials, bounded redirects, content sniffing, byte limits before full reads, and a preference for local push/upload or short-lived signed URLs over arbitrary fetches. Callbacks can also carry an error field for a correlated request when the agent or orchestrator has exhausted its reply paths but has no visible result. That keeps operators out of long timeouts and makes no-reply failures explicit.

There are two complementary integration shapes:

The second shape is where generated Starlark and shared SQLite coordination become useful. Agents should be able to propose glue, but Calciforge should require operator-reviewed Starlark before changing policy or routing. For async work, a standard SQLite queue can give agents and orchestrators a durable coordination surface without forcing every integration to run a bespoke daemon.

Extension Points

Recipes may eventually need small pieces of glue code rather than only command and environment configuration. The goal should be constrained extension, not arbitrary plugin execution.

Possible extension surfaces:

A shared SQLite contract is especially interesting for local-first orchestrators. It could provide a durable, inspectable queue:

work_items(id, target, state, requested_by, created_at, updated_at, prompt)
work_events(id, work_id, kind, body, created_at)
artifacts(id, work_id, path, mime_type, size_bytes, created_at)
approvals(id, work_id, reason, state, created_at, decided_at)

The security boundary is important:

Longer-Term Vision

Text chat remains the baseline, but agents are moving toward richer outputs and longer-running workflows: generated images, reports, traces, audio/video, screenshots, resumable jobs, and multi-agent work state. Calciforge should make those outputs flow through one security and delivery model instead of adding bespoke behavior for each channel or each upstream tool.

The durable product promise should be: bring your agent runtime, and Calciforge adds identity, policy, proxying, secrets, artifact hygiene, auditability, and remote delivery.