Overview
invisible-string is a multi-tenant cloud platform for AI agents. You give an Agent a role, a model, and the tools it needs, then chat with it like a teammate — or delegate standing work to a Workflow, a pipeline that fires from Slack, forms, webhooks, or a schedule. Runs stream live, pause for your approval, and are yours to run wherever you host them: every published Agent compiles into a real, self-hosted eve agent on a durable, Postgres-backed worker pool.
Agents
An Agent is a role you define, fully described by three decisions: Persona (who
it is and how it works), Model (powerful/balanced/quick, resolved within
the workspace's model allowlist — each preset carries a reasoning effort as
well as a model), Context (MCP connections and authored skills, packaged into
the compiled agent). An Agent isn't a prompt template: publishing it produces a
standalone, version-pinned build, and that build is what you chat with.
Workflows
For standing work, delegate with a Workflow: a trigger (webhook, form, Slack
event, or schedule) and a pipeline of steps the platform interprets when
it fires — deterministic tool calls on the workspace's MCP connections,
cheap infer model calls, real agent sessions, and loop/branch/filter/state
control steps, wired together with @ references into the trigger's data and
each other's outputs. The deterministic 90% of a job runs without burning a
model turn; only the steps that need judgment are agentic. A Workflow builds
nothing — publishing is instant.
How it fits together
An Agent starts as a draft in the agent editor — a persona, a model preset, and whatever connections or skills it needs — and nothing runs until you publish it. See Agents.
Publishing compiles that draft into a real eve agent project, runs the build, and stores the resulting artifact by content hash — an unchanged definition never rebuilds, so republishing after an unrelated edit is often instant too.
Once published, an Agent is something you can chat with directly or delegate
to. Chat starts a session and streams every run live; a Workflow instead runs
its pipeline whenever its trigger fires, and any agent step in that pipeline
dispatches the bound Agent's current published version as a child run — no
chat window required. See Workflows.
Every agent run — chat or delegated — lands on a stateless worker pool backed by Postgres, so a worker dying mid-run doesn't lose the run: it resumes on whichever live worker picks it up next. Pipeline runs are just as durable, on the control plane's own step ledger. See Durability.
Chat or a Workflow?
| Chat | Workflow | |
|---|---|---|
| Shape | Interactive — a back-and-forth conversation | Standing — fires on its own trigger |
| Who starts it | You, by typing | A webhook, form submission, Slack event, or schedule |
| What runs | One Agent, conversationally | A pipeline of steps — an Agent only where a step needs one |
| Where output lands | The chat thread you're reading | Wherever the steps put it, plus a per-step timeline in the Runs tab |
| Does publishing build anything | Yes — compiles and builds the Agent | No — publishing a Workflow is instant |
What a Workflow is not
A Workflow carries no persona and no model of its own — its infer steps
borrow workspace presets, and its agent steps borrow published Agents whole,
equipment included. You don't chat with a Workflow directly; you describe it,
publish it, and read its runs.
Where to go next
- Build one — follow the Quickstart to build, publish, and delegate to your first Agent end to end.
- Understand the model — read Agents for how persona, model, and context become a published version.
- Run it yourself — Deploy your own covers self-hosting the whole platform.
Unfamiliar term along the way? Check the Glossary.