LANVAR
← The shelf

Agentic SaaS Starter

Escaped the lab

Turn the SaaS you already have into an agent platform — an open-source agent layer with plans, approvals, parallel runs, and evals that sits on top of your product instead of rewriting it.

PythonLangGraphFastAPIPostgresReact 2026
How it actually works
AGENT_PLATFORM/AGENTS/ ZERO CORE-FILE CHANGES echo_agent/ one node — copy me support_agent/ ReAct loop · citations task_agent/ plan-and-execute flagship LLM ROUTER reads every description.yaml · echo_agent · support_agent · task_agent billing_agent/ description.yaml · graph.py · billing_agent billing_agent/ description.yaml · graph.py · billing_agent routable · in the playground · targeted by evals $ python -m agent_platform new-agent billing_agent
FIG 1 · the folder drop — scaffold it, drop it in, and startup puts it on the roster
AGENTS ARE FOLDERS · TOOLS ARE FOLDERS ZERO CORE-FILE CHANGES dev console chat · traces · evals live graph playground LLM router picks the agent from its description.yaml echo_agent/ one node support_agent/ ReAct · knowledge/ task_agent/ plan-and-execute tools/ — folders run() + schema prompt.yaml few-shots each a thin wrap of a REST call you already expose your SaaS API your tokens, forwarded mocks/ same shapes, offline until SAAS_API_URL points at prod → task_agent, unrolled: triage plan approve run ∥ clarify sum up no free text a human, always “which Sam?” Postgres checkpoints pause, crash, resume observability every run · step · token eval harness baselines + LLM judge drop a folder in — routed, rendered, testable at startup. the tenth agent costs the same as the first.
FIG 2 · the machinery — folders discovered at startup, your API the only source of truth
The story

Every SaaS is getting the same feature request right now: “can I just tell it what I want?” The tempting answer is a rewrite. The starter is the lab’s counter-position, in running code: the agent layer goes on top of the product you already have. A “tool” is a thin wrapper around a REST endpoint your product already exposes — no parallel business logic, no second source of truth — and until you point SAAS_API_URL at a real backend, every tool runs an in-process mock with identical shapes, so the whole platform works offline from the first clone.

The convention is the architecture: agents are folders, tools are folders. An agent is a description.yaml the router reads plus a graph.py that builds it; a tool is a run(), a Pydantic schema, and a prompt.yaml with few-shots. Drop a folder in and it’s discovered at startup — routable, rendered in the playground, targetable by evals — with zero changes to core files. One scaffold command stamps out a new one in seconds, and the three bundled agents are graduated templates to copy from: echo_agent is one node, support_agent is a ReAct loop, task_agent is full plan-and-execute. The tenth agent costs the same as the first.

The other discipline: nothing destructive happens without a human. Free text becomes a typed plan the user approves before anything runs; approved items fan out in parallel; and when a tool can’t resolve something — “assign it to sam,” which Sam? — the run pauses mid-flight, asks, and resumes exactly where it stopped. State is checkpointed in Postgres, so all of it survives crashes. Identity never moves either: users log in with your SaaS’s own tokens and the layer forwards them on every call. The agent adds convenience, never privilege.

Around the core sits what a team actually needs to ship: an LLM router choosing between specialized agents, observability down to the token, a multi-turn eval harness with versioned baselines and an LLM judge, and a prompt playground that re-runs any node against real history without redeploying. It’s MIT-licensed — and it’s also the shape of the lab’s consulting offer. When a company asks for their product “but agentic,” this is the starting line.