Your workflows, written by your team.
A pack is how work gets on the machine: the plans, the specialists they name, and the systems they may reach. Ours ship as packs, and so can yours, as files, uploaded in the console, running under the same signature and record as everything else.
Seven steps, from a folder to a running plan.
Everything above ships as a pack: the plans, the specialists they name, and the systems they may reach. Your team can write one too, as files rather than code that runs on our platform, and it runs under the same signature, the same limits and the same record as everything else.
| Step | What happens |
|---|---|
| Write it | A manifest, plans in the plan grammar, the specialists, and the endpoints the work needs. A checker runs on your own machine and names the file and the line. |
| Upload it | An administrator uploads the folder as a zip in the console. Nothing installs unless it validates. |
| See what it asks for | A review screen lists its plans, its specialists, the integrations it uses, the exact hosts it wants to reach and the secrets it needs, before anything is installed. |
| Approve it | Asking and approving are separate acts, recorded against named people. A node can require a second approver for anything that reaches a private system or needs a secret. |
| Connect it to your systems | An integration is an endpoint you run next to your own data. The platform reaches it through the egress gateway, its credential lives in that workspace, and the agent never holds it. A test-connection check tells you it is reachable before you rely on it. |
| Sign it | An uploaded plan arrives unsigned and waits for a named person. After that, changing the plan or a specialist stops it running until it is signed again. |
| Run it | It appears in the console for the people who do the work, on a schedule, or behind the API trigger, with its inputs as a form, and the record underneath. |
Our own packs install exactly the same way; the only difference is that they carry our release signature. A pack from outside may not bring code that runs on your box: no engines and no apps. The upload refuses it and names the key at fault. Versions are pinned: a pack declares the platform range it needs, and the installer refuses a mismatch.
Four kinds of file, and nothing that runs on your box.
| File | What it is |
|---|---|
| The manifest | What the pack contains, the platform version it needs, the endpoints it will ask for and the secrets those need. |
| The plans | Phases, steps, which specialist does what, which integration each step may use, and where a person signs. |
| The specialists | An agent per domain: either a full forged persona, or a short one that is just a model and a system prompt. |
| The integrations | A declaration of the endpoint you run next to your data, what it is called, and which secret it needs. The endpoint stays yours; the pack only names it. |
A pack from outside may not carry code that runs on your box. The upload refuses it by name, and says why.
Bring a workflow you already run by hand.
We write the first pack with you on a call: the plan, the specialists, and the endpoint it needs. You keep the files.