A Piece of PI – Embedding The OpenClaw Coding Agent In Your Product

What is actually happening inside OpenClaw when it appears to acquire a new capability? That question brought Matthias Luebken to Pi. An OpenClaw meetup prompted him to investigate the machinery behind the behavior, rather than the more spectacular things people were doing with it. Building agents for organizations at TAVON.ai, he wanted components he could understand and reuse. He offers companion examples in that experimental spirit: Pi’s minimal foundation makes it possible to take an agent apart, and his understanding of how best to use it is still changing.

The first useful comparison is Unix tool composition. Luebken introduces the principle of programs doing one thing well with a slide attributing it to Ken Thompson, then turns to Cowork in the Claude desktop experience. Cowork packages a coding agent for work that does not look like software development. In a finance workflow, for example, the user needs to work with Excel spreadsheets. Luebken describes its spreadsheet skill as using pandas, openpyxl and LibreOffice tools rather than directly operating Excel. The product capability comes from composing smaller tools behind a task-oriented interface.

Luebken reports positive reception to Cowork, but the architectural opportunity matters more here than reception: make the system easy for an agent to use. The emerging pattern, sharpened in a conversation with Ivan, is to expose capabilities in forms the agent already handles well. Unnecessary complexity makes that harder. There is no settled playbook in this account; the way to discover useful product patterns is to build accessible tools and experiment with their composition.

Pi is an open-source, minimal starting point for this exploration. Luebken mentions its author Mario Zechner joining Earendil, then gives a practical way to begin: open Pi and ask it to build the functionality you want. Extensions can be downloaded or written, including with the coding agent’s help. The goal here is not to improve everyday development inside a coding assistant, but to find out what else its machinery can power.

Start one layer below the coding agent. A core agent receives a goal and context—often instructions in AGENTS.md—and runs tools in a loop:

1. Give the model the goal and relevant context.
2. Let it request a tool call.
3. Execute the tool and return its result.
4. Continue with the new information until the agent can produce its response.

The application-specific behavior comes from the context, tools and controls attached to that loop.

Pi exposes this through a TypeScript agent class that accepts prompts and provides an event system. Luebken’s first demonstration is a terminal CRM lead qualifier, which he describes as a three-file TypeScript application. The request is straightforward: show all leads and score them. The trace reveals the assistant calling tools, receiving results and eventually returning its output. Its system prompt describes the available tools and when to use them. This is a small learning prototype, built quickly to make the loop visible.

The tool boundary is also where the application can intervene. Before a contact-update tool runs, a hook can check whether the operation should proceed. Luebken suggests authorization and role-based access as uses for that interception point. The important distinction is between an agent requesting a mutation and the application permitting it: a proposed contact update does not have to become an executed update.

An application-level TypeScript wrapper makes that ordering explicit. Here the contact update remains pending until a confirmation callback allows it; only then can the write function run:

type ContactUpdate = {
  contactId: string;
  email: string;
};

type UpdateResult =
  | { status: "blocked" }
  | { status: "updated" };

async function updateContactWithConfirmation(
  proposed: Readonly<ContactUpdate>,
  confirm: (update: Readonly<ContactUpdate>) => Promise<boolean>,
  write: (update: Readonly<ContactUpdate>) => Promise<void>,
): Promise<UpdateResult> {
  const pending = Object.freeze({ ...proposed });

  if (!(await confirm(pending))) {
    return { status: "blocked" };
  }

  await write(pending);
  return { status: "updated" };
}

This is the ordering a before-tool-call gate enforces. A confirmation decision is one application control; complete authorization still requires deciding who may perform the requested operation.

Events handle the other side of execution: telling the interface what happened. The terminal stream subscribes to agent activity, and a check mark indicates that a tool call completed and returned a result. The hook controls whether execution proceeds; the event subscription makes its progress and outcome visible.

A coding agent retains the same tool loop but adds a runtime and shell, commonly Bash. It can now execute programs as part of solving a task. The goal, context, tool requests and returned results remain; the execution environment expands what those requests can accomplish.

Luebken illustrates the difference with an anecdote Peter shared about OpenClaw receiving a voice message. In that account, OpenClaw initially had no voice-message capability. It assembled a way to handle the input using available tools, including FFmpeg on the local machine. Luebken does not establish whether a dedicated voice plugin was available by the time of this presentation. The mechanism he emphasizes is tool composition: behavior that looks like learning from the outside can arise from executing another tool inside the loop.

The next CRM example moves from the core agent class into the Pi coding agent’s extension API. Two capabilities matter most for this demonstration: session events and UI interaction. A TypeScript extension registers a /pipeline command, loads the CRM context and presents a selection through the extension’s UI context. The workflow can now ask the user to choose, instead of relying entirely on free-form prompting and backend tool calls.

The demonstration runs inside the downloaded Pi coding agent. Invoking the new command brings up selection controls, including dropdowns. That changes what the extension can express: it can combine an agent session with explicit user decisions. Luebken again suggests asking the coding agent to generate an extension, but notes that Pi’s extension framework is oriented toward coding-agent use cases. Turning it into a framework for other kinds of applications requires more work.

A web interface is the next experiment. Luebken shows a web-UI concept he asked Pi to build, carrying over the same command and selection interaction using the extension mechanism. He describes limitations in the available support and refactoring underway to make the integration cleaner. Treat this as an exploration of moving the interaction out of the terminal, rather than a claim that the demonstrated web interface was a finished, generally available Pi feature.

OpenClaw expands the setting from one coding agent in one session to multiple channels, threads and agents. In the architecture Luebken describes, OpenClaw uses Pi’s core packages and invokes an embedding function that creates an agent session and streams information back. Session support is therefore useful outside the terminal: an enclosing application can own the interaction while reusing the execution machinery.

The packages divide the responsibilities into reusable layers:

OpenClaw adds its own plugin mechanism because its requirements extend beyond a coding session: multi-channel routing, provider orchestration, sub-agents and gateway support. This is the historical Pi integration presented in the recording. Current OpenClaw runtime documentation instead describes an OpenClaw-owned runtime and @openclaw/agent-core; those current internals should not be substituted into this walkthrough.

The client application begins with a sales process: customers email requests for proposals for systems or parts the company sells. Instead of exposing a coding-agent interface, the team starts with the incoming email. A monitored inbox feeds a gateway, which routes messages to an agent assigned to the customer.

The customer agent combines instructions at different scopes:

• General harness: An instruction file such as AGENTS.md defines the agent’s role, how to use the system and how to respond to inputs and outputs.
• Customer context: A customer Markdown document supplies customer-specific access, perks and discounts.
• Case session: Each case creates or reuses a session, preserving what has already been discussed as messages go back and forth.

The customer determines which context applies; the case determines which conversation continues. This lets the application retain continuity without making the user manage agent sessions directly.

Once an email reaches its customer agent and case session, tools connect the agent to the CRM and ERP. Those systems provide the business information it needs, including contact details. The team exposes these capabilities as CLIs because Luebken finds agents effective at using them. This applies the opening design principle directly: make the relevant business operations accessible through interfaces the agent can already work with.

Luebken reports that the team uses its own sandbox and secures the data before producing drafts, while acknowledging that its sandboxing work is still developing. The earlier confirmation hook and this execution boundary serve different purposes. A gate can stop a particular tool operation; it does not by itself restrict filesystem, process, network or credential access. Pi’s current documentation explicitly places those restrictions outside the agent, requiring external isolation.

The team is also investigating NVIDIA OpenShell and its policy approach as a possible way to secure agent execution. It is an option under consideration, not a component Luebken reports having deployed in the client system.

The final demonstration shows the application from the inbox outward. The dashboard displays incoming email. An LLM relevance decision ignores most messages and selects the illustrated message for processing. That email is associated with a case, and the case is backed by an agent session. The system then performs the work needed to produce a draft response. The user can remain in the familiar inbox-and-drafts workflow.

The dashboard is primarily an administrative view. Behind the draft, the session trace shows the assistant working through the request; in the German-language example, it looks up articles or items, calls tools, receives results and continues the loop. For the user, that activity resolves into something much simpler: an incoming email belongs to a case, and an editable draft is ready. Automatic sending is not part of the described outcome.

This is the product shape Luebken is betting on: coding agents as reusable software building blocks, embedded behind an interface appropriate to the work. His closing invitation is to experiment with Pi because its minimalism makes its pieces easy to take apart and recombine. The sales assistant completes that progression—from a visible terminal tool loop to an application where the user works in email and the agent machinery stays underneath.