01 / 13
← →   SPACE   SWIPE
Puller's AI agent runtime — v2
Internal alignment · eng / product / leadership

From fixed workflow to secure workbench.

Why we give the agent a fresh, locked room for every job — and why that is a product bet, not a chatbot upgrade.

Live proof of concept · PowerPoint skill already ships decks with visual QA
01 / The difference
One picture

A vending machine
versus a workshop.

A1

Scripted workflows

Every button is programmed in advance. It does exactly what we predicted — nothing more.

Reliable for a fixed menu. A new dish means rebuilding the machine.

versus
{ }

Sandboxed runtime

We give the AI a locked room, tools, and a goal — it figures out the steps.

Flexible enough for brand-new work. The room is demolished when the job ends.

02 / Meet the system
One metaphor family: room + concierge

A tiny company assembled for one task.

HQ
Puller

The dispatcher

Takes the request, sets the rules, and keeps the job record.

OPS
Worker executor

The building manager

Opens the room, enforces limits, and demolishes it when done.

VM
Firecracker microVM

The locked room

A private, temporary computer. Mistakes stay inside.

π
Pi agent

The craftsperson

Plans, uses tools, fixes its own mistakes, and delivers.

HOW
Skill package

The instruction manual

Teaches a new kind of task — no product reprogramming required.

GO
Capability broker

The trusted concierge

The only way out of the room — and only for pre-approved actions.

03 / Isolation
Firecracker builds the room. Pi works inside it.

A temporary private room inside a bigger computer.

One real serverthe whole building
ROOM 01
DONE
Previous job erased
ROOM 02
π
WORKING
This job only
ROOM 03
EMPTY
Ready for another
01

Create a clean room

Start from a trusted template. Add only this job’s manuals and tools.

02

Keep the work inside

Cap compute, time, network, and what the room may touch.

03

Erase the room afterward

Export the deliverable, revoke every temporary pass, demolish the room.

04 / Product velocity
What “add one capability” means on fixed rails

A feature request crosses the whole company.

01 / REQUEST Define the exact workflow

Every branch anticipated in advance.

02 / BUILD Engineers write the code

Every tool, failure, and edge case by hand.

03 / VERIFY Test every path

Security, billing, output quality.

04 / SHIP Release a new version

Coordinate across the product.

05 / USE User finally gets it

Until their next variation.

POWERFUL FOR REPEATABLE WORK · EXPENSIVE FOR OPEN-ENDED WORK
05 / Walk one job
Make the machinery feel real

One request. No product release.

User request

“Build a competitor deck for Acme — our notes, brand kit, and three public sources.”

Skill: polished presentation v1.4 Spend cap on AI: fixed for this run Outside actions: read CRM notes only Write HubSpot? Not on this pass
Result → .pptx + activity log · room destroyed · no release shipped
01 · ASK User states the outcome

Not every click — the goal, inputs, and deadline.

02 · BOUND Puller sets the rules

Manual, permissions, spend, and time limits.

03 · OPEN A clean room boots

Temporary passes only. Real keys stay in the vault.

04 · WORK Pi builds the deck

Plans, uses tools, self-checks slides inside the room.

05 · CHECK Sealed handoff to a reviewer

A different AI inspects. Weak slide? Send back exact fixes.

06 · CLOSE Deliver and demolish

Export the deck, revoke passes, erase the room.

06 / One request, seven verbs
The whole story — once

Ask. Bound. Open. Work. Act. Check. Close.

“ ”Ask

User describes the outcome — not every click.

[ ]Bound

Instructions, spend, permissions, deadline.

▣Open

Building manager creates a clean locked room.

πWork

Craftsperson plans, tools, self-fixes inside.

→Act

Concierge performs only approved outside moves.

✓Check

Independent inspector grades the sealed result.

×Close

Deliver files, revoke keys, destroy the room.

Under the floorboards: Grant → Mint → Boot → Work → Act → Collect → Destroy · same arc, system verbs
07 / Where control sits
Application owns the mission · runtime owns the method

The production map.

Puller's side — who the user is, what they want, what's allowed
ProductUser interface

Where the goal is stated.

ControlJob manager

Starts, schedules, tracks.

AuthorityRulebook

What this job may and may not do.

Host Supervisor

Builds the room, enforces limits, demolishes it.

π / PI
This job’s instruction manuals
Tools: files, documents, code
Throwaway workspace
AI accessLimited pass

Fixed spending cap.

OutsideConcierge

Acts for the user, within limits.

ResultsWork + log

Files plus full activity record.

Outside — passwords and keys stay here; they never enter the room
PullerUser data
ProvidersCRM / email / calendar
StorageFinished work
08 / Teaching work · acting outside
Expansion unit + only door out

Skills teach procedure.
The concierge holds the keys.

Skill package / v1.4
Polished presentation
  • → design direction
  • → scripts + templates
  • → quality checklist
  • → outside actions it may request
Inside the roomPi requests an action

“Create this approved contact in HubSpot.”

→
Trusted conciergeCheck before acting

Right user? Allowed? Approved? Within limits? Not a duplicate?

→
External serviceHubSpot performs it

A cleaned result returns to the room.

▣The real HubSpot password stays in Puller’s vault. It never enters the room.
.pptxPresentationsBuilt, then visually checked
.pdfPDF workflowsRead, assemble, inspect
crmConnected actionsPre-approved, one at a time
09 / Flexible inside · hard outside
We do not trust the agent with the keys to the building

Disposable trust zone.
Independent inspection.

Real passwords

Vault only — never in the workroom.

Rules in code

Enforced by the system, not by hoping the model behaves.

User approval

When an action changes the outside world.

RUN
SCOPED

Locked room

Think, write, use tools, make mistakes — safely. Compute, time, network, and permissions capped from outside.

Temporary AI pass

One job, fixed dollar cap, then dead.

Short allow-list

Only the outside actions this job needs.

Full paper trail

Actions, files, checks — including failures.

MAKE
Pi worker

Creates the deliverable

Request, files, tools, creation history.

→
SEALED
work + checklist
+ activity log
→
CHECK
Independent reviewer

Fresh eyes

Different AI, no maker memory — approve or send exact fixes.

10 / Neither replaces the other
Certainty where we can · flexibility where it matters

The honest comparison.

Dimension
Scripted workflows
Sandboxed agent runtime
Predictability
Excellent
Managed, not absolute
New capabilities
Needs an engineering release
A new instruction manual
Open-ended work
Poor fit
Natural fit
Speed + cost
Faster and cheaper
Slower, with a spending cap
Infrastructure
Standard, well-understood
Harder to build and run
User extensibility
Limited to what we ship
Users can teach new work
11 / The architecture decision
Hybrid is the answer

Puller owns the boundaries.
The agent owns the route.

Puller decides

Who, what, and whether.

Identity and tenant isolation What the user asked for Permissions and approvals Secrets, billing, activity record
CONTROL
≠
MICROMANAGE
Agent decides

How to finish the job.

Plan and sequence the work Use tools and write code Follow the skill manuals Self-check, fix, and deliver
We are not building a chatbot.
YesterdayEvery capability was a product release.
TodayPi builds and visually checks real decks inside a disposable room.
TomorrowAny task a user can teach — safely, within limits we control.
The product bet

Teach the agent new work — without handing it the keys.

Scripted workflows stay for predictable product paths. The sandboxed runtime is how we buy flexibility without buying liability.

2independent AIs — maker + checker
0real passwords in the room
1disposable computer per job
∞skills without rewriting the app
KeepLangGraph rails for known, metered product flows.
AddLocked-room runtime for open-ended, skill-taught work.
NeverPut master keys, long-lived secrets, or unbounded network in the room.
v2 · tighter arc · one job story · hybrid decision · built from the frontend-slides workflow