Building Production Coding Agents with Pi Framework for Sales Process Automation

tavon · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Coding-agent-based sales process automation

Tavon needed to automate request-for-proposal handling for a parts-selling client without building one brittle monolithic workflow. Incoming emails needed to be routed to customer-specific agents, enriched with CRM/ERP data, kept in case sessions, and turned into editable draft responses while preserving security and human review.

Constraints:

The field of coding-agent architecture is rapidly evolving, with few authoritative patterns.
Customer-specific discounts, access, quirks, and response behavior vary enough that one generic agent would be hard to maintain.
Agents need access to CRM and ERP data but should use interfaces that are easy for coding agents and safe for production systems.
RFP/email cases span multiple interactions, so the system must reuse prior session context.
Customer-facing emails carry business risk, so drafts should remain human-editable before sending.
Coding agents with shell access require sandboxing and security controls that are still maturing.

Architecture

The system uses Pi/OpenClaw-style coding agents for a sales automation workflow. An inbox monitor detects incoming RFP-related emails. A gateway routes each email to the right customer-specific agent. Each agent combines a general agent harness/configuration with a customer-specific Markdown configuration containing quirks such as discounts or access. Case sessions are created or reused so follow-up emails retain context. Agents call CLI tools that expose CRM and ERP operations inside a sandbox, gather customer/product information, and generate a draft email. The human user stays in the familiar inbox, reviews or edits the draft, while an admin dashboard exposes sessions, tool calls, and traces.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  email-inbox-monitor["Email inbox monitor"] --> gateway-router["Gateway router"]
  gateway-router --> openclaw-orchestration-layer["OpenClaw orchestration layer"]
  openclaw-orchestration-layer --> pi-agent-runtime["Pi agent runtime"]
  openclaw-orchestration-layer --> customer-specific-agent["Customer-specific agent"]
  pi-agent-runtime --> customer-specific-agent
  agent-harness-config["Agent harness config"] --> customer-specific-agent
  customer-config["Customer config"] --> customer-specific-agent
  customer-specific-agent --> session-store["Session store"]
  customer-specific-agent --> crm-cli-tools["CRM CLI tools"]
  customer-specific-agent --> erp-cli-tools["ERP CLI tools"]
  crm-cli-tools --> sandbox["Sandbox"]
  erp-cli-tools --> sandbox
  customer-specific-agent --> email-draft-interface["Email draft interface"]
  email-draft-interface --> human-sales-user["Human sales user"]
  session-store --> admin-dashboard["Admin dashboard"]
  event-stream["Event stream"] --> admin-dashboard
  pi-agent-runtime --> event-stream

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Email inbox monitor`	Watches the sales inbox for incoming RFP or sales-process emails.	`Gateway router`, `Email draft interface`
`Gateway router`	Classifies relevant emails and routes each case to the appropriate customer-specific agent.	`Email inbox monitor`, `Customer-specific agent`, `OpenClaw orchestration layer`
`OpenClaw orchestration layer`	Provides multi-channel routing, provider orchestration, sub-agent support, gateway support, and embedded Pi sessions.	`Gateway router`, `Pi agent runtime`, `Customer-specific agent`
`Pi agent runtime`	Core agent loop, session support, event system, coding-agent runtime, LLM abstraction, and terminal/UI extension mechanics.	`OpenClaw orchestration layer`, `Customer-specific agent`, `Session store`, `Event stream`
`Customer-specific agent`	Per-customer agent configured with general harness instructions and customer-specific rules for RFP handling.	`Gateway router`, `Agent harness config`, `Customer config`, `Session store`, `CRM CLI tools`, `ERP CLI tools`, `Email draft interface`
`Agent harness config`	General role, harness, and instructions describing how the agent should use systems and react to inputs/outputs.	`Customer-specific agent`
`Customer config`	Customer-specific Markdown/configuration for discounts, access, quirks, requirements, and communication preferences.	`Customer-specific agent`
`Session store`	Creates and reuses sessions per case so prior email context and agent actions are retained.	`Pi agent runtime`, `Customer-specific agent`, `Admin dashboard`
`CRM CLI tools`	Small command-line tools that expose contact and customer data to coding agents.	`Customer-specific agent`, `Sandbox`
`ERP CLI tools`	Small command-line tools that expose product, inventory, pricing, and order-system data.	`Customer-specific agent`, `Sandbox`
`Sandbox`	Execution boundary for coding-agent tools and sensitive data access.	`CRM CLI tools`, `ERP CLI tools`, `Customer-specific agent`
`Email draft interface`	Keeps humans in their inbox by placing generated draft responses where they can review, edit, and send.	`Email inbox monitor`, `Customer-specific agent`, `Human sales user`
`Human sales user`	Reviews, edits, and approves draft emails while staying in the email workflow.	`Email draft interface`, `Admin dashboard`
`Admin dashboard`	Shows cases, sessions, tool calls, results, and generated draft traces for monitoring and troubleshooting.	`Session store`, `Event stream`, `Human sales user`
`Event stream`	Streams agent events, tool-call status, and results for UI updates and observability.	`Pi agent runtime`, `Admin dashboard`

Data flow

An email arrives in the monitored inbox. The gateway classifies whether the email matters and routes it to a customer-specific agent. The system associates the email with an existing case/session or creates a new session. The agent reads its general harness and customer-specific configuration, then loops through CLI tool calls to CRM and ERP systems to gather contact, pricing, inventory, or case details. Tool events and results stream back through Pi/OpenClaw session mechanics. The final output is a draft email placed in the user's email workflow, with underlying session traces available for debugging.

6 supporting quotes

“we're we're new fresh new thinking, right? And look at the process from the get-go. So, um an email comes in, right? We we we monitor basically that inbox. Then we have some gateway because what we want to do is we want to forward this to different agents. Right? So, here I have”transcript, stated

“we have some gateway because what we want to do is we want to forward this to different agents. Right? So, here I have um multiple agents, right? Uh the way it's structured is we have one agent per customer. And that agent has a general harness, right? Agent”transcript, stated

“to forward this to different agents. Right? So, here I have um multiple agents, right? Uh the way it's structured is we have one agent per customer. And that agent has a general harness, right? Agent MDE um Agent MDE as an example, but you can obviously also use different”transcript, stated

“for each case, right? We're we uh creating and reusing existing sessions so we can back and forth um um know what what was previously talked about. All right. So, email comes in. We're looking at the uh inbox and we route this to these different agents. And”transcript, stated

“we have these different tools uh to talk to the CRM, to talk to the ERP, um and get the right information out of the system for this agent to look on like like behave. Like, you know, maybe it has, you know, new contacts information or or that sorts. And”transcript, stated

“draft. Uh so, there's tons of calls, which I'm going to show you in a second, but basically the output of all that is a draft email that the user will be able to use, right? So, our thinking is uh let them users stay in in email. Let them stay in the the inbox and drafts, and they don't”transcript, stated

Why this architecture

The architecture follows the principle of making systems easy for coding agents. Rather than complex bespoke integrations, CRM and ERP access are exposed as focused CLI tools that agents can compose. Customer-specific agents isolate variation by customer, while sessions preserve continuity across sales cases. OpenClaw adds production coordination around Pi's minimal agent/session/runtime mechanics. Human draft review reduces customer-facing risk while still automating data gathering and response drafting.

5 supporting quotes

“one architectural pattern that we're seeing is that make it easy for coding agents, right? Now, that is very broad, but think about it, right? Like like make not don't try to be, you know, very um complex and things, but think about the the coding agent, what is it good at, and how do I build my”transcript, stated

“Thompson, um inventor of uh Unix, and this is the famous quote by him, uh one of the quotes, "Write programs that do one thing and uh one thing well." And um I really like that because that's that's kind of like works uh to our advantage with agents. And um the best part”transcript, stated

“way currently is doing this with CLIs, right? So, CLIs our agents are really good at using CLIs, so we make it available as a CLI. We put We make sure that the data is secure. Uh we have our own sandbox, and then we're creating the drafts again. Right? So, that's the system, and I hope by this”transcript, stated

“agents. Right? So, here I have um multiple agents, right? Uh the way it's structured is we have one agent per customer. And that agent has a general harness, right? Agent MDE um Agent MDE as an example, but you can obviously also use different”transcript, stated

“will be able to use, right? So, our thinking is uh let them users stay in in email. Let them stay in the the inbox and drafts, and they don't even, you know, need to do a lot. So, this is more like an admin interface they can stay in email but basically the output would be a draft generated.”transcript, stated

Models used: LLM agent · Pi agent core · Pi coding agent · unified LLM abstraction

Scale

The company describes itself as a small European company building agents for organizations.
“we're creating a small company uh Seven AI. We're building agents for organizations. Small out of Europe”transcript, stated
The implementation was built for a client sales process involving requests for proposals for parts.
“And this is one of the applications we've been building for a client and basically the use case is a sales process.”transcript, stated
“They get requests for proposals of of an ordering another another system, right? parts. parts being sold by that company.”transcript, stated
The system runs multiple threads and multiple agents in a multi-channel environment rather than a single coding-agent session.
“a multi-channel uh environment where uh we have um you know, multiple threads going on, multiple agents going on.”transcript, stated
The inbox contains many emails, most ignored, with relevant emails associated to cases and agent sessions.
“it's one of one of many emails. Most of them are ignored, but this one is like the the the LM call said, "Okay, I'm I'm interested in this."”transcript, stated

Alternatives considered (roads not taken)

A single general sales/RFP agent

Rejected because: Customer-specific quirks, access, discounts, and instructions are better isolated in one agent/configuration per customer.

“the specific customer might have, you know, specific quirks, right? Specific um uh access, specific um um discounts”transcript, stated

Direct complex integrations for backend systems

Rejected because: The team chose small CLI tools because coding agents are good at composing command-line utilities.

“it talks to uh Excel, right? Well, it doesn't. Uh instead, it uses a uh a set of small tools, small CLI, um uh Pandas, uh OpenPyXL, and uh stuff from LibreOffice, and package this into their own skill uh to make it uh up and running. And I think this is a great example to kind of get you going,”transcript, stated

“our way currently is doing this with CLIs, right? So, CLIs our agents are really good at using CLIs, so we make it available as a CLI. We put We make sure that the data is secure. Uh we have our own sandbox, and then we're creating the drafts again. Right?”transcript, stated

Automatically send sales emails

Rejected because: The system generates drafts for humans to review and edit in their existing inbox rather than sending directly.

“for the user is I'm looking at my inbox there's a new email it's associated to a case and I get a new draft which they can freely edit but under the hood we have all these agents working. All right, that's that it it's for me again. Here here you find the slides key takeaways please coding agents”transcript, stated

Rely on Pi alone as a single-session coding-agent environment

Rejected because: Production use needed OpenClaw's multi-channel routing, provider orchestration, sub-agent, gateway, and plugin support layered around Pi.

“not only talking about like like um a single agent in a single session in a coding environment, uh but now we have a multi-channel uh environment where uh we have um you know, multiple threads going on, multiple agents going on. So, there's a little bit more”transcript, stated

“Open Claw has built its own plugin mechanism and that's because you know, it's a different use case, right? And has different requirements.”transcript, stated

Patterns

`tool-use-orchestration` (coding-agent-tools)

The system exposes CRM and ERP functions as CLI tools so coding agents can call and compose them inside their loop.

“An agent is actually just an LLM agent that runs tools in a loop”transcript, stated

“we have these different tools uh to talk to the CRM, to talk to the ERP”transcript, stated

`multi-agent-orchestration` (routing)

A gateway routes emails to multiple customer-specific agents, with OpenClaw adding routing, provider orchestration, sub-agent, and gateway support around Pi.

“Then we have some gateway because what we want to do is we want to forward this to different agents. Right? So, here I have um multiple agents, right?”transcript, stated

“plugin support for a multi-channel routing different provider orchestration sub agents gateway support”transcript, stated

`agent-memory` (state)

Each case is associated with a reusable Pi/OpenClaw session so later emails preserve prior discussion and tool-call context.

“I like using sessions. Then for each case, right? We're we uh creating and reusing existing sessions”transcript, stated

“Now, this case is again is an agent session, right? Uh so, we find the session and associate it to it.”transcript, stated

`human-in-the-loop-gate` (approval)

The agent produces draft emails for the user to edit and approve rather than sending customer-facing responses automatically.

“Uh so, there's tons of calls, which I'm going to show you in a second, but basically the output of all that is a draft email that the user will be able to use, right?”transcript, stated

“The end effect for for the user is I'm looking at my inbox there's a new email it's associated to a case and I get a new draft which they can freely edit but under the hood we have all these agents working.”transcript, stated

`observability-tracing` (operations)

Session events, tool-call streams, admin dashboard views, and case association make the agent's actions inspectable.

“you have an event system, so you know a lot of things that that that are going on.”transcript, stated

“now I'm looking at the articles it does different tool calls right? It gets gets results and does this in a loop to resolve”transcript, stated

`privacy-preserving-processing` (security)

The team exposes data through CLIs inside its own sandbox and explicitly calls out security/sandboxing as an evolving requirement.

“We put We make sure that the data is secure. Uh we have our own sandbox”transcript, stated

“sandboxing etc. And and to be honest, we're on the uh just on the on the steps of of getting there”transcript, stated

Tradeoffs

Expose business systems through CLI tools

Chose Small command-line tools for CRM/ERP access over Complex bespoke interfaces that are harder for coding agents to use.

Rationale: The speaker argues coding agents are good at CLIs and that Unix-style small tools compose well for agent workflows.

“This is Ken Thompson, um inventor of uh Unix, and this is the famous quote by him, uh one of the quotes, "Write programs that do one thing and uh one thing well." And um I really like that because that's that's kind of like works uh to our advantage with agents.”transcript, stated

“CLIs our agents are really good at using CLIs, so we make it available as a CLI.”transcript, stated

Keep users in email

Chose Generated drafts in the existing inbox over A new primary sales-agent UI for day-to-day users.

Rationale: Users can stay in the email environment they already use, while the dashboard remains mostly for administration and tracing.

“let them users stay in in email. Let them stay in the the inbox and drafts”transcript, stated

“this is more like an admin interface they can stay in email but basically the output would be a draft generated.”transcript, stated

Layer OpenClaw on Pi

Chose OpenClaw production plugins around Pi core mechanics over Using only a single Pi coding-agent session.

Rationale: The sales system needed multiple channels, threads, providers, subagents, and gateway routing beyond Pi's minimal core.

“not only talking about like like um a single agent in a single session in a coding environment”transcript, stated

“Open Claw has built its own plugin mechanism and that's because you know, it's a different use case”transcript, stated

Use draft generation instead of full automation

Chose Human-editable responses over Autonomous outgoing sales emails.

Rationale: The source does not claim the system is safe enough for autonomous customer communication, so human review contains business risk.

“a new draft which they can freely edit but under the hood we have all these agents working.”transcript, stated

Gotchas (what bit them)

Coding-agent patterns are still unstable.

Root cause: The speaker says the field lacks authoritative resources and that the same talk would likely change within weeks.

Resolution: Use minimal frameworks like Pi for tinkering and keep architecture flexible as patterns emerge.

“Because there are no patterns, right? We need to figure this out. We're seeing some emerging patterns in the coding space, right?”transcript, stated

“I'm going to do the talk again in a couple of weeks and it's going to be most likely be different.”transcript, stated

Shell-access agents need deliberate security and sandboxing.

Root cause: Coding agents can execute tools and access business data, making open-shell policy and sandbox boundaries central to deployment risk.

Resolution: Run CRM/ERP CLIs inside a sandbox and continue evaluating open-shell security approaches.

“We put We make sure that the data is secure. Uh we have our own sandbox”transcript, stated

“OpenClaw, their policy their open shell is really really interesting”transcript, stated

One customer-facing sales agent would mix too many customer-specific rules.

Root cause: Customers differ by discounts, access, quirks, and how systems should be used or responses handled.

Resolution: Use one agent per customer with a general harness plus customer-specific configuration.

“Uh the way it's structured is we have one agent per customer. And that agent has a general harness, right? Agent MDE um Agent MDE as an example, but you can obviously also use different ones.”transcript, stated

“the specific customer might have, you know, specific quirks, right? Specific um uh access, specific um um discounts”transcript, stated

Without sessions, follow-up emails lose sales-case context.

Root cause: RFP cases involve back-and-forth communication and prior tool results.

Resolution: Associate each case with an agent session and reuse it for later messages.

“creating and reusing existing sessions so we can back and forth um um know what what was previously talked about.”transcript, stated

Evaluation

The source demonstrates behavior through a running dashboard/email demo, session association, visible tool-call traces, and draft outputs, but does not describe a formal eval suite or quantitative accuracy metrics.

Metrics: Whether an incoming email is classified as relevant. · Whether the email is associated with the correct case/session. · Tool-call traces and returned results visible in the admin dashboard. · Whether the final draft email is usable and human-editable. · Sandbox/security posture for CLI tools.

4 supporting quotes

“Most of them are ignored, but this one is like the the the LM call said, "Okay, I'm I'm interested in this." And it is associated to a case, right?”transcript, stated

“And it is associated to a case, right? We see the case up there.”transcript, stated

“it does different tool calls right? It gets gets results and does this in a loop to resolve”transcript, stated

Outcomes

Tavon built a client-facing sales automation system that monitors email, routes RFPs, creates/reuses sessions, queries CRM/ERP tools, and generates draft emails.
The case demonstrates a per-customer agent pattern for managing customer-specific business rules.
The implementation uses coding-agent-friendly CLI tools, sandboxing, and admin trace visibility.
The source positions coding agents as a future core building block while acknowledging that patterns and security practices are still emerging.

The source describes a working client application but does not provide counts for RFP volume, customers, accuracy, or time saved.