plsbro

Don’t just tell an AI agent please, bro and hope. PLSBRO gives every task a contract, sandbox, budget, verification, and audit trail.

Comment

Inspiration

Most AI-agent products start with a request like “please do this,” then ask us to trust whatever happens next.

As agents gain access to files, APIs, money, and production systems, prompt quality is no longer enough. Users need to know what an agent is allowed to do, what data it can access, how much it can spend, what evidence proves the work was completed, who verified the result, and whether the execution environment was destroyed afterward.

PLSBRO turns those questions into an explicit, enforceable task contract before execution begins.

What it does

Our demonstration runs a platform-owned CSV-cleanup agent.

Before execution, the user sees and approves:

  • The fixed synthetic input
  • Permitted operations
  • Declared output artifacts
  • Deterministic success criteria
  • A deny-all network policy
  • A one-model-call ceiling
  • A $0.00220000 budget reservation

The agent runs inside an isolated Vercel Sandbox using a two-stage Python runner:

  1. Inspect the task and request one structured column-mapping decision.
  2. Execute the approved transformation and produce the declared artifacts.

The sandbox has no OpenAI key, no secrets, and no external network access. The model request is handled by the trusted control plane, which sends only CSV headers and platform-owned metadata—not private row values—to the OpenAI Responses API.

The agent produces:

  • cleaned.csv
  • reconciliation.json

A separate TypeScript verifier then checks that:

  • Required columns are present
  • Status values are normalized
  • Duplicate rows were removed
  • Input and output counts reconcile
  • The files are valid UTF-8
  • Only declared artifacts were created
  • The output matches the task contract

The result is accepted only after those checks pass.

How I built it

PLSBRO combines:

  • Next.js and TypeScript for the control plane and interface
  • Python 3.13 for the sandbox runner
  • Vercel Sandbox for isolated execution
  • OpenAI Responses API with strict structured output
  • JSON Schema and versioned contracts
  • Integer-based budget accounting
  • Independent artifact verification
  • Hash-linked platform audit evidence
  • Docker-backed runtime and protocol tests
  • GitHub Actions for Linux integration and end-to-end validation

The wider foundation also includes transactional lifecycle auditing, leased work execution, retry recovery, stale-worker rejection, idempotency, artifact checksums, and restricted runtime images.

The demo intentionally uses a fixed synthetic CSV instead of arbitrary uploads. This makes the workflow safe, repeatable, and objectively verifiable while demonstrating the underlying execution architecture.

Live result

The successful browser-based execution produced:

  • One actual model call
  • Zero simulated model calls
  • 106 input tokens
  • 32 output tokens
  • A verified cleaned CSV
  • Confirmed sandbox deletion
  • A complete audit timeline

At published rates of $1 per million input tokens and $6 per million output tokens:

  • Input cost: 106 × $1 ÷ 1,000,000 = $0.000106
  • Output cost: 32 × $6 ÷ 1,000,000 = $0.000192
  • Total measured cost: $0.000298

This stayed well below the reserved maximum of $0.00220000.

Challenges

The hardest part was not getting the model to clean a CSV. The difficult part was proving that the surrounding system behaved correctly.

I had to separate:

  • Agent-generated artifacts from platform-generated evidence
  • Model generation from deterministic verification
  • Sandbox permissions from control-plane permissions
  • Simulated results from live results
  • Budget reservation from actual cost reconciliation

Sandbox cleanup also had to occur on success, failure, malformed evidence, timeout, and interruption paths.

Another major challenge was maintaining parity across macOS development, Linux containers, and GitHub-hosted CI. Differences in filesystem permissions, process reaping, command behavior, runtime environment variables, and Node installation layouts exposed assumptions that local tests did not initially reveal.

Deployment introduced additional lessons around secret handling, access-code protection, disabled-first releases, restricted API keys, and kill-switch restoration. PLSBRO defaults to live execution being disabled and enables it only during controlled demonstration windows.

What I learned

The largest lesson was that trustworthy agents require more than a capable model.

A useful trust layer needs:

  1. A specification before execution
  2. Least-privilege isolation during execution
  3. Bounded spending and provider access
  4. Independent verification after execution
  5. Auditable evidence for every important transition
  6. Fail-safe cleanup on every terminal path

I also learned that “the tests are green” is not the same as “the boundary is proven.” Adversarial review repeatedly found cases where evidence could be ambiguous, cleanup could fail, or one operating system behaved differently. Treating those findings as part of the design process made the final system materially stronger.

What’s next

The CSV workflow is a focused demonstration of a broader idea.

The next step is to generalize the contract, execution, verification, and audit layers so developers can safely define additional workflows. Arbitrary uploads, external tools, and marketplace distribution would come only after the corresponding privacy, permission, and verification boundaries are proven.

PLSBRO turns autonomous work from a black box into a bounded, verifiable process—from an explicit contract, to isolated execution, to an audit-ready result.

See every boundary. Trust every result.

Built With

Share this project:

Updates