Harness · Pi

Pi on the Software Lifecycle Cloud

Pi on KERNSTACK means the open-source, provider-agnostic terminal coding agent working in a KERNSTACK repository — with Mistral, Devstral, or whichever model you point it at. Pi’s appeal is that the harness is small, scriptable, and model-neutral; KERNSTACK’s side of the contract is identical to every other harness: branches for agent work, kernstack plan --json for a checkable change set, and a deploy gate between the agent and production.

Agent Sandboxes Hosted Git stack.json IaC

Talk to us Read Technical Documentation → Software Lifecycle Cloud →

Bring your own model, keep the same guardrails

Pi exists for people who want to choose — or change — the model without changing the workflow, including European models such as Mistral’s Devstral line. That choice is entirely yours to make in the harness. The repository does not care: code under functions/, workers/, and apps/, the stack.json that declares the runtime, and seed data beside it. A session that swaps models mid-project leaves the same kind of branch behind.

Scriptability is where Pi earns its place in automated setups: headless sessions that run a defined task, read kernstack plan --json, and stop. “Stop” is the operative word — the plan is output for a human or a downstream check, not a permission slip the script grants itself.

What the platform enforces, whoever holds the keyboard

Guardrails on KERNSTACK live in the platform, not in harness configuration, which is why a minimal harness is enough. Agent work can be confined to agent/ branches with their own agent- environments. Deploying outside that environment asks for confirmation. Destructive plan entries need an explicit flag. A project deploy gate can require review-approved source no matter which tool produced the commit.

Model and provider choice (Mistral Devstral and others) stays inside Pi — the platform is deliberately model-agnostic
kernstack git checkout agent/ lets a person inspect the exact state a Pi session produced
Headless runs should end at plan output; deploy remains the gated, human-approved step

Supported Models & Workflow

Supported Models & Engines: Mistral / Devstral · Any provider Pi supports — your choice

Pi — Developer & Agent Workflow cli · sandbox

pi session edits code + stack.json (any model)
kernstack plan --json -> structured change set
Human reviews branch + plan
kernstack deploy (deploy gate enforced by the platform)

stack.json — Governed Target Stack plan · deploy

{
  "stack": { "target": "prod" },
  "gateway": { "routes": [] },
  "resources": {}
}

FAQ

Frequently asked questions

Why use Pi instead of a vendor’s own coding agent?

Model freedom and a small, inspectable harness: Pi lets you run different providers — including European model families — through the same terminal workflow and extensions. If a model gets better or cheaper elsewhere next quarter, your KERNSTACK workflow does not change at all.

Can Pi run unattended in CI-style automation?

It can run headless tasks, and the sane pattern is: agent edits, kernstack plan --json reports, automation stops. Shipping then goes through the project’s deploy gate, which can require review-approved source. Unattended production mutation is a policy you would have to deliberately dismantle, not a default.

Does KERNSTACK need to add support for each model Pi runs?

No. The platform contract starts where the harness ends: branches, plans, deploys. That separation is the point — today’s Devstral session and next year’s model produce identical artifacts for review, so swapping models never means re-litigating how changes reach production.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →