Skip to content

For experts (consultants)

You're the method-owner. You encode your expertise as an archetype (a reusable agent definition), run it on real work as a placement, and — when it's ready — package it for a client without handing over your method. This page is your workflow hub: each step is badged with its honest status, and the harder questions (versioning, deploy configuration, what to do when something breaks) are linked below.

What you can actually do today

Only the local desktop workbench is shipped: build → run → review on your own machine, plus collaboration across machines via federation. Available

Handing an agent to a remote client (cross-party packaging and deployment) is implemented and tested in the core but not yet operationally live. Built live deployment Planned The single source of truth for every capability's status is the Roadmap & status table.

Where your data goes — read this once

GaugeWright orchestrates locally, but it does not run the model locally. The agent's reasoning is performed by the third-party LLM provider you configure (e.g. OpenAI, Anthropic, Azure OpenAI), so your prompts and the in-scope context are sent to that provider over the network. With your own credentials, the provider is your subprocessor, not GaugeWright's. There is no local-only inference today. See Where your data goes. Available

The three-step workflow

Step What you do Status
1. Build an agent Define an archetype and refine it in an edit chat. Available
2. Run & review work Place it on a project, give it tasks, keep or discard the diffs. Available
3. Package & deploy Make it shareable and deploy it to a client (privately, or under attestation). Built live deployment Planned

The progression is deliberate: you build the method in isolation, run it against real (or sample) context to prove it works, and only then package it for someone else. Each step reads from and writes to an append-only history, so the whole trail — every method change, every run, every release — is auditable and reversible. Available

Step 1 — Build an agent Available

You author the method in an edit chat — a chat rooted on the archetype itself. The definition is the Pi-native surface in the archetype's own repo (ADR 0029); you edit these files directly in the content viewer, or tell the agent in the edit chat to improve them:

  1. In your library, create a new archetype and name it for the method (e.g. price-leveling).
  2. Edit the persona / system prompt in .pi/SYSTEM.md — who the agent is and how it works.
  3. Edit working conventions in AGENTS.md — the rules and conventions the agent should follow.
  4. Set model/provider, declared tool requests, and the protection posture in .agent-config.json (this is GaugeWright's own governance file — the membrane policy — not a Pi method file).
  5. Install skills/packages in chat: tell the edit chat to install what you need; it runs the install as a tool call, writing the archetype's own .pi/skills/, .pi/extensions/, and .pi/settings.json. There is no separate skills form.

A running agent cannot rewrite its own method — structurally

The method surface (.pi/**, AGENTS.md, .agent-config.json) is writable only from an edit chat. A work chat (rooted on a placement) can read the definition but never mutate it. This is a structural, machine-checked guarantee (INV-24): the definition surface is mounted read-only by an OS kernel sandbox, so even a bash shell inside a run can't change it — bubblewrap on Linux, Seatbelt on macOS. Available (Linux/macOS) The Windows sandbox is Planned (AppContainer / restricted token) — see Roadmap & status.

Full walkthrough: Build an agent.

Step 2 — Run & review work Available

To do work you install the archetype onto a project — that's a placement — and chat with it in a work chat:

  1. From the project, install the archetype. The placement's identity always shows its lineage as archetype · project (e.g. price-leveling · Peach), so which method is running and where is never hidden.
  2. Attach context — the files or folders the agent works on, as context resources. Attaching records intent; the boundary decides what is actually revealed during a run.
  3. Give it a task in the work chat. Each run executes inside an isolated sandbox and produces a diff — the proposed change.
  4. Keep or discard the diff. Nothing is applied without your decision, and every run is recorded in the append-only history.

Inference leaves your machine on every run

During a run your prompts and the in-scope context are sent to your configured LLM provider. If data may not leave for a third-party model, use a provider you've contracted, or wait for confidential inference (Planned). See Where your data goes.

Collaborate by syncing multiple chats into a shared workstream, and across machines via federation — nothing crosses without the source permitting it to leave and the target admitting it. Available

Full walkthrough: Run & review work.

Step 3 — Package & deploy Built live deployment Planned

When the method is ready, freeze a version and package it. A package is a shareable manifest that makes the archetype transferable across parties without turning transfer into execution or payload release. A published version is immutable — a deployed agent never silently changes under a client.

The cross-party guarantees:

  • Your method stays protected — it runs read-only at the client and is never exported or revealed.
  • The client's data stays protected — the agent reads context only under the client's explicit grants.
  • Crossing requires both sides — anything moving carries proof that you permitted it to leave and the client admitted it. Available (federation transport)

Not yet operationally live

Packaging and cross-party deployment are implemented and tested in the core, but operational deployment to a remote client is not yet live. The building blocks (federation transport, the boundary, output review, the attestation verifier) exist today; go-live wiring is pending. See the Roadmap & status.

Full walkthrough: Package & deploy.

Going deeper

These pages answer the questions experts hit once the three-step loop is familiar:

  • Versioning & forking — freezing an immutable version, how placements take an upgrade deliberately, and forking an archetype (owner-only) to branch genuinely different behavior. Built
  • Deploy configuration — the .agent-config.json knobs (model/provider selection, declared tool/capability requests, and the membrane policy — the protection posture) live in Build an agent → Set the model and protection posture; the deployment options (private peer-to-peer vs. attested compute) live in Package & deploy → Deploy. Built live Planned
  • Troubleshooting — unsigned-build prompts, provider credential and model-resolution issues, sandbox/permission errors, and what to check when a run is denied (fail-closed by design). Available

Structural guarantees vs. operational posture

Keep these two kinds of claim separate when you reason about trust:

These are built into how the system works and paired with adversarial tests that fail if the protection is removed:

  • A handle is not access; method and context reads are both explicit.
  • A run has no ambient authority — it does only what it was admitted to do.
  • A work chat cannot rewrite the method (INV-24) — kernel-enforced on Linux/macOS; Windows Planned.
  • Fail-closed: a missing, stale, or uncertain grant is denied.
  • Append-only history: every durable fact is an immutable event.

See How GaugeWright protects your work.

These depend on configuration, infrastructure, or process and are not structural guarantees today:

  • Inference confidentiality depends on your provider's terms — the LLM sees prompts and in-scope context. Planned (confidential inference).
  • Live cross-party deployment / hosted / embed are Built or Planned, not live.
  • Third-party certifications (SOC 2 Type II, DPA, pen test) are Planned; builds are currently unsigned.