The AIBAST RAPP pattern

Every agent here is a shell template: the template is the shell, and your real business process is what it wraps around, live, from the first minute.

Agents Library · Production Guide · Install the Brainstem

What a shell template is

A library template is not a finished app and not a demo with made-up data. It is the shape of an agent for one business job: what it asks, what it reads, and what it hands back. That shape is the shell. Your process is the content.

The shell (ours)The agent's shape for a use case: the questions it asks, the records it reads, the steps it follows, the output it hands back. Same shell for every customer with that job.
The content (yours)Your live process: the system where the records really live, the steps your people actually follow, the people who approve. Different for every customer, never copied into the shell.

This applies to all three layers: the Brainstem (the local engine), RAPP (the method) and every template in the AI Agents Library.

What it wraps around

How a use case fills the shell, live

  1. Install. One line puts the Brainstem on the laptop. Sign in with GitHub. The chat page opens.
  2. Pick the template. Choose the library template for the job (say, Time Entry & Billing) and drop its agent file into the chat.
  3. Point it at the process. Tell it, in plain words, where the records live and who does what. That is the only customer-specific part.
  4. It works on the live process from minute one. Ask it a real question about a real record. The shell is the same one every customer gets; the answers are yours.

The chat is the whole control surface. Nothing is configured anywhere else.

What the shell must never do

Own or copy your business data. The shell reads the live process and writes back through your own system of record. It keeps no second copy of your customers, hours or invoices, so there is nothing to get stale, nothing to migrate, and nothing new for security to review beyond the connection itself.

This is the lesson others paid for before us. Rails scaffolding and the Salesforce object model both won by shipping the shape and letting the customer's live data fill it. Every tool that copied the data into its own store spent years on sync problems instead.

A worked example: Time Entry & Billing

The shell (same for every firm): capture hours against a matter, flag entries that break the billing rules, draft the invoice lines, hand the draft to the billing lead for approval.

The content (one law firm): matters and rates live in their practice-management system; entries over 8 hours a day need partner sign-off; the billing lead is one named person who approves in Teams.

What happens live: a lawyer tells the agent "log 2.5 hours on the Henderson matter, drafting the motion". The agent writes the entry into the firm's own system, checks it against the firm's rules, and when the month closes it drafts invoice lines from the firm's real entries and sends the draft to the billing lead. Switch to a second firm and the shell is untouched; only the three sentences of content change.

How a maker builds a new one in the hour

  1. Describe the job in one paragraph: what it asks, what it reads, what it hands back. That paragraph is the shell.
  2. Write it as one agent file (agents/your_job_agent.py): a short description for the model and one perform() that does the work. The Brainstem picks it up on the next message, no restart.
  3. Point it at a live process with plain words in the chat, and ask it a real question.
  4. When it holds up on a real record, it is a template. Share the file; the next customer only changes the content.

The 14-step Production Guide takes the same shell from prototype to production, with the human quality gates in between.