STARKMISSION AGENT RUNTIMESchedule a briefing

Stark Runtime

One runtime for every agent team.
One clear line of authority.

Bring multiple agents, local and frontier models, mission tools, human approvals, and reviewable evidence into one runtime. Your software remains the only system authorized to change mission state.

Discuss Stark licensingReview deployment

Built for mission ownership

Add intelligence without handing over the keys.

Stark gives each part of the system one clear job, so model reasoning can move quickly while mission authority stays exactly where the program put it.

01 / AUTHORITATIVE

Mission host

  • Authoritative domain state
  • Operational time and cadence
  • Identity, permissions, and policy
  • Consequences and persistence
02 / GOVERNED

Stark Runtime

  • Concurrent agent sessions
  • Tools, schemas, and credentials
  • Provider and policy handoff
  • Lifecycle, meter, and evidence
03 / UNTRUSTED

Model provider

  • Receives bounded context
  • Reasons over available tools
  • Returns typed proposals
  • Never applies consequence

Execution contract

Every agent turn has a beginning, a boundary, and an end.

The host opens a decision window, Stark constrains role and authority, a provider returns a proposal, and native policy closes the loop with a recorded host decision.

  1. 01

    Observe

    Host emits bounded state

  2. 02

    Constrain

    Runtime exposes available authority

  3. 03

    Propose

    Model returns a typed action

  4. 04

    Admit

    Native policy accepts or rejects

  5. 05

    Apply

    Host owns the consequence

  6. 06

    Record

    Facts support audit and replay

What programs can build on today

A working core, with a roadmap you can evaluate honestly.

The runtime foundation is implemented. Deployment claims and planned product layers stay clearly labeled until their own evidence and acceptance gates close.

Concurrent agent sessions

Implemented

One supervised sidecar can admit multiple isolated agent sessions against a shared compatible model process; the retained fixture exercised two concurrent commanders.

Bounded decision windows

Implemented

The host supplies an explicit observation and available authority for each decision window.

Typed tools and proposals

Implemented

Model output is parsed into host-defined action types before policy evaluation.

Deterministic host admission

Implemented

Native policy accepts or rejects proposals; the model cannot bypass the gate.

Interrupt, resume, and metering

Implemented

Runtime lifecycle and decision-window facts can be recorded for audit and controlled replay.

Shared local model sidecar

Process supervision implemented

Model-keyed process supervision, authenticated loopback transport, shared slot admission, and explicit reap are implemented. A two-commander fake-responder fixture exercises that boundary; real GGUF inference, restart policy, and packaged-binary qualification remain pending.

Frontier provider routing

Implemented

Provider contracts support connected model endpoints through the same bounded runtime surface. Endpoint approval, provider-specific qualification, and local/frontier conformance evidence remain program-specific and are not yet published.

Signed mission packs

Planned

Versioned packaging for agents, tools, policies, evaluations, and controlled offline import is a planned product surface, not a delivered assurance control.

Verified offline operation

Deployment-specific

Requires a named executable, model, host, network boundary, measurement procedure, and acceptance record.

Start with Rust. Fit the boundary to your system.

Stark offers a direct Rust SDK today. For software in other languages or across multiple processes, Pinpoint designs the right adapter or service boundary around the interfaces you already own.

One reusable core, tested in a demanding host

The reusable runtime and shared sidecar are maintained in chat-sdk. BLACKBODY exercises that core inside a real-time simulation with game-owned policy and adapters. The supervised process boundary works today; packaged model hosts, restart policy, and real-model qualification are the next release gates.

Show only what matters
Turn host-owned state into the focused mission context each agent role is allowed to inspect.
Translate intent safely
Map structured proposals into native policy checks before the host permits any consequence.
Keep work bounded
Define startup, cancellation, timeouts, teardown, and what must settle before work is complete.
Preserve a reviewable record
Record inputs, proposals, gate outcomes, timing, and replay identity without relying on hidden model reasoning.

Product direction

Start with the core. Grow into a full mission platform.

Stark begins with an implemented runtime and expands into controlled deployment, mission packaging, and program evidence. Planned layers remain roadmap direction until their release gates close.

01 / CORE

Stark Runtime

Embeddable agent orchestration, provider contracts, typed tools, policy handoff, lifecycle, and evidence.

Core implemented
02 / DEPLOY

Stark Edge

A planned controlled-deployment profile for local models, provenance, offline import, and operational continuity.

Planned
03 / PACKAGE

Stark Mission Packs

Planned versioned bundles of agents, tools, permissions, prompts, evaluations, and mission-specific policy.

Planned
04 / ASSURE

Stark Evidence

Planned artifacts and evaluation workflows that connect observable runtime facts to program acceptance criteria.

Planned

Start with the mission boundary

Bring the system you trust.
We’ll map governed agents around it.

Keep all initial inquiries unclassified and non-sensitive. Do not send controlled data, credentials, export-controlled material, or system artifacts through the public website.

Schedule a mission briefing