When a team adds another coding agent, what should move with it?
The easy answer is "everything." Model credentials, runtime plugins, tool permissions, session history, project instructions, reusable skills, and command shortcuts all feel like one bundle when the work is moving fast.
They are not one bundle. Moving executable or credential-bearing state is a different trust decision from projecting plain-text workflow resources into places a tool already understands.
AIWG 2026.9.1 adds Pi Coding Agent as its twelfth named provider integration. The Pi adapter takes the narrower route first: deploy startup context, Agent Skills, managed skills, and prompt templates into Pi's native resource surfaces. It is an experimental first-class integration, with the limits documented next to the capabilities.
What Pi is
Pi is a terminal coding-agent harness built around a small core and explicit extension points. The official project description is direct: Pi is a minimal agent harness that should adapt to your workflow, not force your workflow to adapt to it.
That shows up in the shape of the tool. Pi can run interactively, in print or JSON mode, through RPC, or as an SDK for embedding. In the normal first session, Pi gives the model a compact default tool set for reading files, writing files, editing files, and running shell commands. Additional read-only project navigation tools are available through options.
Pi also treats customization as a first-class surface. Users can add TypeScript extensions, Agent Skills, prompt templates, themes, and Pi packages. That matters for AIWG because our own provider integration is strongest when the target tool has native places for reusable workflow material to land.
Who makes Pi
Pi is built in the open under the earendil-works/pi repository and published through the @earendil-works npm package namespace. The project site identifies Earendil Inc. as the company behind Pi, and the repository describes Pi as the home of the Pi agent harness project, including the self-extensible coding agent, agent core, and multi-provider AI layer.
The public repository is MIT licensed. The license file credits Mario Zechner for the original 2025 copyright, and Mario's public governance note says Pi is now an Earendil product with him at the helm alongside Armin Ronacher and Colin. For this announcement, that is the safe attribution: Pi is an Earendil product, built in the open, with Mario Zechner as the public technical lead.
What stands out
Pi is interesting because it makes the harness itself part of the working surface. It ships with useful defaults, but it deliberately leaves some larger workflow features out of the core. The project calls out sub-agents and plan mode as examples: instead of baking those in, Pi expects users to build, install, or package the workflow they want.
That is a different posture from a sealed coding assistant. Pi exposes places to add commands, tools, provider behavior, UI components, themes, prompt templates, skills, and packages. It also has a large model/provider story: Pi's provider docs cover subscription providers, API-key providers, cloud providers, llama.cpp, and custom providers, with built-in catalogs and cached model metadata.
The session model is also worth understanding. Pi stores sessions as trees, so a user can move to an earlier point, fork, clone, resume, export, or share a session instead of treating the chat transcript as one linear stream. That makes Pi a natural fit for developers who want to inspect how agent work branches over time.
The tradeoff is explicit. Pi does not include a built-in permission system that restricts filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it. Pi documents containerization and sandboxing options for teams that need stronger boundaries.
Where Pi is going
Pi's public roadmap is visible through its RFCs and release notes. The active direction is consistent with the product shape: keep the core small, make the extension ecosystem stronger, and make operational behavior more inspectable.
Three roadmap threads are especially relevant to AIWG users:
- Installation trust: RFC 0047 proposes moving the curl installer and
pi updatetoward a managed install path backed by reviewed lock artifacts, staged installs, validation, and atomic activation. - Model metadata: RFC 0039 proposes moving from a large committed generated model catalog toward provider-scoped dynamic catalogs served by
pi.dev, while preserving offline fallback behavior. - Analytics and privacy: RFC 0038 describes opt-in analytics experiments plus anonymous aggregate request tracking, with user-visible controls and payload transparency as the policy direction.
None of those roadmap items are promises from AIWG. They are useful context for why Pi is a provider to watch: the project is not only adding agent features, it is working on the operational edges around installs, model catalogs, extension behavior, and user trust.
Try the boundary before reading further
Sort these into two groups:
AGENTS.md, reusableSKILL.mdinstructions, and prompt templates.- API keys, model selection, executable extensions, packages, and trust decisions.
The current integration owns the first group. The second stays under Pi and the operator's control. That separation is the point.
What AIWG deploys for Pi
From a project directory, preview before writing anything:
aiwg use all --provider pi --dry-run
Then deploy and inspect:
aiwg use all --provider pi
aiwg doctor --provider pi
aiwg steward capabilities --provider pi
AIWG maps project context through AGENTS.md, portable roles and Agent Skills through .agents/skills/, managed skills through .pi/.aiwg/skills/, and user-facing workflow prompts through .pi/prompts/.
This is native-resource integration, not a hidden compatibility shim. Pi already discovers the context, skill, and prompt surfaces; AIWG adapts its reusable material to those conventions and tracks deployed files through its normal receipt lifecycle.
One word, two provider selectors
There is a naming trap worth remembering:
aiwg ... --provider piselects AIWG's Pi coding-agent integration.pi --provider ...selects an LLM backend inside Pi.
AIWG does not translate or merge those namespaces. Choose the coding harness in AIWG and the model backend in Pi.
What the integration does not do
AIWG does not install Pi, write Pi settings, choose a model, inject credentials, install packages, or add executable extensions. Runtime extensions, model-catalog integration, and persisted-session ingestion remain future work.
Project-local Pi skills and prompts are also subject to Pi's trust model. Review the project, approve trust interactively when appropriate, and restart Pi so trusted resources are discovered. Trust is not a sandbox: Pi runs with the permissions of the process that launched it unless you add a separate containment layer.
Why this matters
Provider portability is useful only when it remains understandable. A team should be able to answer what moved, where it landed, what can execute, what stayed operator-owned, and how to remove managed artifacts.
Pi support extends AIWG's reach without pretending every coding agent has the same native surface. The common workflow stays portable; the provider adapter stays honest about the tool it is targeting.
Connect and verify
Use the AIWG Pi quickstart for installation, trust, user-scope, and troubleshooting details. For Pi itself, start with pi.dev, the Pi documentation, and the earendil-works/pi repository. Then run the dry-run, inspect the deployment, and tell us which AIWG workflow you want to run in Pi first.
Tools and transparency
This article was drafted with AI assistance, then edited for voice, claims, and publication fit. Product behavior should be verified against the AIWG repository and Pi documentation on the day this post is promoted. The primary hero image was generated by the operator and includes both Pi and AIWG marks; third-party brand usage should be reviewed before broad syndication.