Self-hosted platform for AI agents · pre-alpha

Run AI agents like production infrastructure.

StarColony is a self-hosted platform that runs AI agents on Temporal, so each model turn and tool call becomes a replayable, budgeted, audited workflow step. The guardrails live in the platform: allowlists, grant tokens, network policy, human approval. Not in the prompt. Today the control plane, encrypted runs, and access layer are running; the agent loop and the tool, sandbox, and approval planes are designed and marked as such below.

Request early access Survey the architecture

CONTROL PLANE AND ENCRYPTED RUNS RUNNING · AGENT LOOP DESIGNED · PHASE 0

  • Temporal durable execution
  • Rust control plane
  • AES-256-GCM payloads
  • Scoped machine tokens
  • Tenant IDs in the schema
  • Audit log, hash chain designed
The problem

Agents don’t fail like software.

Most teams run agents the way they’d never run a service: steered by prompts, holding broad credentials, losing state on restart, leaving no record of what they actually did.

FAULT 01

The lost run

A worker dies forty minutes into an investigation. The context was in process memory. Start over, and pay for every token again.

FAULT 02

The polite guardrail

“Please don’t delete anything important” is a steering suggestion, not a control. One injected instruction and the prompt is working for someone else.

FAULT 03

The standing credential

The agent holds an org-wide token in an environment variable, for every run, every tool, indefinitely. Compromise the worker, inherit the keys.

FAULT 04

The invisible action

Which tool did it call? With what arguments? Approved by whom? If the answer lives in stdout, the answer is gone.

Prompts are steering, and they were never brakes. The brakes have to be built into the platform.

One fabric, two workload kinds

Agents and pipelines are peers.

Both run on the same durable Temporal fabric. Agents reason and choose tools; pipelines pull, crawl, and normalize. Neither is a bolt-on to the other. Both kinds can be registered today; the agent runtime itself is designed, not built.

Docking bay A — Agents

The durable AgentLoop (designed)

One workflow type will run every agent, with each LLM turn and each tool call as a workflow activity:

  • replayable and resumable, because every step is workflow history
  • budgeted: turns, tool calls, and spend capped per definition
  • tool intents checked against the grant in deterministic code
  • results land in the evidence store; state carries pointers, not payloads
Docking bay B — Pipelines

Any workflow, any language

The bring-your-own-worker contract is a registration shape, not an SDK:

task_queue     byo-data-team
workflow_type  WarehouseFreshnessCheck
payload       JSON

Registered through the same API as everything else. Any Temporal SDK language can serve the queue, though today every payload is encrypted with a StarColony codec that a non-Rust worker would have to reimplement; worker kits for other languages are planned.

Durability

Kill the worker and keep the run.

Because every step is recorded workflow history, a run that loses its worker resumes from its last step: same run, nothing repeated. Proven so far for a conformance workflow through a worker outage and a rollout; budgets are designed.

The edges are meant to be durable too. Deterministic run identities already collapse API retry storms into exactly one run: a repeated Idempotency-Key returns the original run, and a changed body under the same key is rejected. The inbound webhook outbox with a redrive sweeper is designed and not yet built; today a signal that cannot reach Temporal is refused rather than queued.

Governance

Each plane names its mechanism and its status.

None of this is enforced by a system prompt. Each governed plane has an enforcement point you can audit, and the chip says whether that enforcement point exists today or is still on paper.

  • Plane 01
    Tools

    A compromised worker cannot call ungranted tools.

    • deterministic allowlist gate
    • grant JWT · 15-min TTL · revocable
    • NetworkPolicy
    Status: DESIGNED

  • Plane 02
    Models

    Code asks for a job class, not a model. Routing by data classification is designed, not enforced yet.

    • job classes → gateway aliases
    • data classification pins routing (designed)
    • per-workload keys · budgets (designed)
    Status: PARTLY BUILT

  • Plane 03
    Evidence

    Workflow history is not a plaintext store of your documents.

    • AES-256-GCM payload codec
    • pointers, not payloads (designed)
    • masked snippets · keyed fingerprints (designed)
    Status: CODEC BUILT

  • Plane 04
    Sandbox

    A coding agent’s maximum authority is opening a pull request.

    • egress-locked ephemeral jobs
    • no push credentials inside
    • GitHub Rulesets as the ceiling
    Status: DESIGNED

  • Plane 05
    Humans

    Consequential actions wait for a human, and the requester can never approve their own.

    • Slack approval on the run
    • separation of duties
    • timeout → auto-deny · fail closed
    Status: DESIGNED
The sandbox

Maximum authority: a pull request.

In the design, coding agents run in ephemeral, egress-locked jobs, and the capabilities you would worry about are not switched off; they are never installed. Nothing in this section is built yet.

Push to main NOT INSTALLED

GitHub Rulesets require a PR and reviews; the app sits on no bypass list.

Hold credentials NOT INSTALLED

Publication tokens are minted outside the sandbox: per run, single-repo, 1-hour TTL.

Open egress NOT INSTALLED

Default-deny network. Two ducts: the model gateway, and a logging proxy path-scoped to the target repo.

Open pull request THE ONE DOOR · DESIGNED

The one door. Plan → human approval → apply in a fresh sandbox → PR.

The infrastructure change lane, also designed, is stricter still: the agent edits config only, the plan output is the reviewed artifact, and apply happens post-merge through your existing pipeline. The agent never holds cloud credentials.

Human-in-the-loop

The approval gate.

Consequential tools are gated on a human decision, delivered where your team already works. The card shows the tool arguments verbatim, so approval fatigue is fought with information rather than volume. Approvals are designed; the card and ledger below are mockups of the design.

Audit ledger (design): hash-chained, append-only

  • seq 41 · tool_call · github.create_pr · held for approval prev 9f3a…c2 → hash 62b1…8e
  • seq 42 · approval · approved · principal m.reyes prev 62b1…8e → hash a04d…71
  • seq 43 · artifact · PR #1847 linked · transcript stored prev a04d…71 → hash 3c9f…d5

In the design, the ledger is written by a role that can insert and never update or delete, and it exports nightly to write-once storage, so a compromised component can stop writing history but cannot rewrite it. Today the audit table exists and records machine-token authentications; the hash chain and the insert-only role are not yet written.

Engine / content split

Security is the first pack, not the point.

The engine is meant to ship no domain semantics. Whole problem domains arrive as content packs: versioned bundles of agent definitions, tool grants, connectors, and record types registered through the public API. The pack mechanism is designed, and the split is not yet enforced in the tree; the first dogfood left DLP tables in the engine’s migrations, and moving them out is on the list.

The engine

Permanent structure
  • Rust control plane, the only HTTP surface
  • Durable execution fabric for agents and pipelines
  • Tool registry, grants, model policy, evidence store (designed)
  • Tenant IDs on workload and run tables
  • Generic typed records, no domain vocabulary (designed)

Pack 01 — Security

Roadmap, deletable by design
  • Cloud-finding triage → remediation pull requests
  • PII scanning across Drive, Notion, and Linear
  • SIEM investigations with approval-gated write-back
  • Slack-native triage and paging, approval-gated

Deleting the pack must leave a complete platform, and the test that will enforce it is written into the plan: a non-security workload must register, schedule, run, and be observable end-to-end with zero engine changes. That check is not in CI yet; the repository has no CI today.

Site survey

What runs, and what is under construction.

StarColony is being built in phases with exit criteria, and the repository sits in Phase 0. Present tense on this page describes the target architecture. Here is where the build is as of September 2026.

Running today

  • Rust control plane: workloads registered with immutable versions, runs started through the API with Idempotency-Key semantics and encrypted start intents
  • A Rust Temporal worker executing conformance workflows; one encrypted run proven through a worker outage and a rollout on 2026-08-11
  • AES-256-GCM payload codec on the API and the worker, fail-closed on decrypt
  • Access plane: Tailscale, Authentik OIDC with PKCE, server-side sessions, admin and user roles from email allow-lists
  • Scoped, expiring, revocable machine service tokens with an audit row per authentication
  • LiteLLM model gateway with six declared job classes; a Slack bot and a browser prompt UI in daily use
  • Local Kubernetes bring-up conductor with the full third-party stack under one command

Also true

An agent with a granted egress channel can still misuse it within the gate’s bounds. Injection resistance is layered: templates, schema-bound notifications, scoped egress. Human approval on consequential tools is the backstop, not a formality.

Local sandboxes are weaker than production sandboxes. On a laptop cluster, isolation degrades, so in the design it is a flagged condition and applying changes from a degraded sandbox requires an explicit override.

Parts of our toolchain are young. The Rust Temporal SDK is in public preview; we pin it exactly and keep workflow code orchestration-thin.

It runs on one laptop today. The stack has only been exercised on a local kind cluster over a private tailnet. There is no published image or chart yet, so “your Kubernetes” is the design target, not a download.

Early access

Design partners wanted.

We are looking for a small number of teams who run Kubernetes, want agents doing real work such as remediation, scanning, or investigation, and want the guardrails in the platform before the agents arrive.

Design partner brief
COHORTdesign partner · early access
RUNS ONyour Kubernetes (design target)
WORKERSRust core · other languages planned
STAGEphase 0 · pre-alpha
Request early access

What you get is a conversation about your workloads and our phases, and a say in the guardrails before they harden.

Autonomy, inside the law.