A task in. Micro-agents out.
plnt runs a parent that reads a task on your repository, decides which agents to create and what each should do, runs them in isolation on a private copy of the workspace, and merges the result into one reply. The decision, each agent’s spec, every file it read and every model call are on the record, live.
# pre-alpha: install from source
pip install "git+https://github.com/plnt-work/plnt"
plnt dev code-reviewer --workspace . # API + console on 127.0.0.1:8787
# open http://127.0.0.1:8787/console → Sessions → New sessionOne task, one parent, as many agents as it takes.
You give a task
“Audit app/store.py for bugs and write tests for it.” On a workspace: a demo repo, a folder, or a git URL.
The parent decides
One structured model call: answer, ask, or spawn. For each agent: which bundle, an intent in your words, what it depends on. Recorded with its reason.
Agents run isolated
Independent agents run in parallel; dependent ones wait and get the upstream results. Each has its own tools, budget and guardrails on the session’s copy.
One reply, full trace
The parent merges the answers. The transcript keeps the plan, every agent’s spec, steps, files and tokens. Watch it in the console or the playground.
What you see while it works.
Recorded from the playground on the notes-api demo workspace, with the events
exactly as the runtime streamed them. Open the playground to run your own.
…
Starting…
What people point it at.
The four shipped bundles cover the coding tasks. Everything else is a bundle you write, or a role the parent invents.
Repo audit
Point the parent at a repository and ask what is wrong with it. It spawns a reviewer per concern and merges the findings with path:line citations.
Test writing
A reviewer finds the behaviour worth pinning down; the test writer, which depends on it, writes the tests in the project’s own framework and runs them when allowed.
Explain a codebase
For a new contributor, a reviewer or a manager: layout, entry points, the main flow, how to run it, what looks unfinished. Always from files it read.
Changelog and release notes
From git history where the agent may run git, or from the code itself where it may not. Grouped as Added / Changed / Fixed, ready to paste.
One task across many repos
The same task on every repository a team owns, one session each, isolated, with usage and audit per tenant. The console shows every run side by side.
Not left to each agent to get right.
A private workspace per session
Every session works on its own copy of the folder or repo. Agents read and change the copy; the source is never touched.
Tools by policy, not by prompt
Read-only mode strips write_file and execute before the agent ever sees them. The public playground runs that way.
Look before you answer
A bundle can require a tool. An answer the model gives before reading a file is withheld, not sent.
Budgets and a kill switch
Token, wall-clock and step limits per agent, a loop detector, and a kill that stops the running agents and skips the rest.
Everything on the record
The parent’s decision and reason, each agent’s spec, every model call, tool call and file, usage per agent. Streamed live, folded into a transcript.
Any model, per tenant
Gemini, OpenAI, or a local Ollama, vLLM or llama.cpp box. Chosen per tenant, checked with plnt models doctor before you rely on it.
Checked before you rely on them.
plnt models doctor checks what an agent needs: the server is up, the model is
pulled, it calls tools, it returns JSON, the context window fits. Failures come with the fix.
$ plnt models doctor
qwen2.5:7b ollama · http://127.0.0.1:11434 · local
✓ reachable http://127.0.0.1:11434
✓ model present qwen2.5:7b
✓ context window requesting 8192 of 32768 tokens
✓ tool calling native; called get_weather(city='Paris')
✓ JSON output got {'answer': 42}$ plnt run code-reviewer "find bugs" --workspace .
✗ cannot reach Ollama at http://127.0.0.1:11434
fix: start it with `ollama serve` (or fix PLNT_LOCAL_URL)
# no silent fallback to a canned answer: a model
# failure is reported as a failure, with the fix.Pre-alpha (0.1). The parent, the four developer bundles, workspaces, the multi-tenant API, the console and the playground are built and tested in CI, including against a real local model. Bundle tool code runs inside the server process, so only install bundles you trust; sandboxed tools, nested parents and a hosted registry are on the roadmap.