You don't have to build Tines 3B workflows only in the app. Because every space is a plain git repository of files, you can clone it into a coding agent like Claude Code, edit steps as source, and push your changes back. This article covers how to connect an agent and the controls you get once you're there.

How the connection works

A Tines 3B space is a git repository. Each workflow is a top-level directory, and each step inside it is a subdirectory of files. When you clone that repository into Claude Code for example, the agent sees your whole space as ordinary code it can read, edit, and commit.

To get the clone URL, open your space settings and find the Git URL section. It looks like this:

https://<your-tenant>/spaces/<space-slug>.git

Clone it like any other repository, and authenticate with a Tines 3B API key as the password:

git clone https://<your-tenant>/spaces/<space-slug>.git

When you push a branch, Tines 3B applies your changes to the workflow. If someone edited the same workflow in the app while you were working, git rejects the push, so you pull, resolve conflicts, and push again. Deleting the main branch is not allowed, and files at the repository root are rejected, since every file has to live inside a workflow directory.

The guidance and scaffolding that ship in the clone

Tines 3B injects a few files into every clone so your agent already knows how the product works. You don't check these in or edit them, because Tines 3B regenerates them automatically:

AGENTS.md and CLAUDE.md. The full reference on how workflows are structured, plus git, CLI, and REST API instructions. CLAUDE.md simply points Claude Code at AGENTS.md.
Step templates in .3b/templates/. Read-only scaffolds for the shell, python, typescript, react, and agent step types. You start a new step by copying one, for example cp -r .3b/templates/typescript "My step".
Skills in .3b/skills/. Deeper guidance on specific capabilities, such as designing storage volumes, building React frontends, and building agentic steps. Your agent reads a skill's SKILL.md before tackling that kind of work.

The controls you get when building

Once your agent is working in the clone, the controls are the files themselves. Here are the main levers.

Step structure and templates

Every step is a directory whose name is the step name (names must be unique within a workflow). Inside, a step has a README.md, a config.toml, a Dockerfile, and the source for its template:

shell runs a script.sh.
python runs a script.py, with dependencies in requirements.txt.
typescript runs a script.ts on Bun, with dependencies in package.json.
react renders a App.tsx as a client-side React app with Tailwind.
agent ships a working model loop for chat or autonomous agents, so you don't hand-roll one.

A step isn't limited to one file. You organize source the way you would in any well-kept project, splitting components, helpers, and types into their own files as a step grows.

Step configuration in config.toml

The config.toml file is where most of the per-step controls live. Every field except color is optional, and you omit a field rather than leaving it empty:

route turns a step into an HTTP trigger at a path you choose, such as /checkout. Keep routes specific to the workflow, and reserve / for the rare case where a space needs a homepage.
route_auth sets who can reach a route. It defaults to space (only members of the workflow's space), and other values include tenant, sso, external_id for webhooks, connector for other workflows, and public. Keep routes private unless you truly need them open.
route_type surfaces a route on the Links page and tells the UI how to present it, using webpage, api, webhook, or other.
cron schedules a step, for example 0 * * * * for hourly. Schedules only fire on the published version, so you test drafts by running them manually.
email_address makes a step receive inbound mail, with the raw message as its input.
timeout caps execution in seconds, from 1 to 300, defaulting to 45. Prefer short timeouts and only raise it for genuinely slow work.
retry_seconds reruns a step after an unsuccessful exit, for example [1, 2, 3]. Add it only when replay is safe, since each attempt restarts the whole step.

Linking steps and moving data

You connect steps with the links array in config.toml: add a downstream step's directory name to an upstream step's links, and the upstream step's stdout becomes the downstream step's stdin. Downstream steps run automatically when their upstream finishes, and linking to several steps fans out to all of them in parallel. A step that writes nothing to stdout stops the flow, which is a handy way to build a filter.

Documenting an API endpoint

For a step marked route_type = "api", you can add an api.json file describing its request and response contract as an OpenAPI operation. This is how a workflow becomes self-describing to other workflows that call it as a connector. You keep the fragment self-contained, and update it in the same commit whenever the endpoint's shape changes.

Persistent storage

Steps share durable state through named volumes mounted under /storage, declared with a VOLUME line in the Dockerfile. You control lifetime with scope, read-only versus writable access, and concurrency for overlapping writers. Before building anything that stores files or state, your agent should load the workflow-volume-design skill to pick the right shape.

Applying and running your changes

You have three ways to work against a space from outside the app:

Git. Commit and push to apply changes, which is the primary path for a coding agent.
The Tines 3B CLI. Install it with curl -fsSL https://<your-tenant>/cli/install.sh | sh, run 3b configure to set your API key, then run or chat with workflows, for example echo "Hello" | 3b run wf_abc123 --wait.
The REST API. Authenticate with Authorization: Bearer <api-key> and use endpoints like POST /api/v1/workflows/:id/run.

Full docs live at /api/v1/docs on your tenant.

Build a workflow in your own coding tools