How Tin runs marketing workflows with Temporal and E2B

Ege Demir — Wed, 11 Nov 2026 13:20:16 +0000

I’m working on Tin, an open-source marketing system for coding agents. This post walks through the architecture in our public repository: how we separate an agent conversation from work that must survive retries, schedules and human review.

Why a chat session is not enough

A marketing task often spans several systems. Research produces files. A content draft waits for review. A scheduled run starts after the original conversation ends. A provider request can fail after an external action has already happened.

The useful unit of work is therefore a versioned workflow attached to a project, with inspectable inputs and durable outputs. The agent helps choose and configure the work; the workflow system tracks its execution.

The components and their responsibilities

Tin exposes a remote MCP endpoint for coding agents. The service uses Python and FastAPI, with PostgreSQL for application state. Temporal coordinates durable execution, and E2B supplies isolated compute. Project repositories hold artifacts beyond the lifetime of an individual sandbox.

The boundaries matter:

MCP: discover workflows, inspect prerequisites, start authorized work and inspect results.
Temporal: coordinate retries, schedules and waits, including pauses for human review.
E2B: execute the steps that need an isolated environment.
Project repositories: retain the files the work produces.
PostgreSQL: maintain the product-facing view of projects, runs and review state.

See the architecture documentation and workflow implementation for the concrete code.

Keep execution history small

Durable execution has a different data model from a chat transcript. Tin’s architecture keeps workflow history focused on identifiers and coordination, while I/O happens in activities. Prompts, credentials and large artifacts do not belong in that history.

This also avoids treating a long execution log as the product database. The UI needs a practical view of the current run and its outputs, while the execution engine needs enough history to coordinate the work reliably. Those responsibilities are related, but they are different.

Version definitions, then inspect before running

A repeatable workflow needs more than a memorable name. Its definition and configuration must be identifiable so that a scheduled run does not silently become a different procedure after an edit. Tin pins workflow versions and exposes inputs and prerequisites for inspection.

From an agent, the basic sequence is discovery, inspection, configuration and execution. Some workflows need a service connection or account resources before they are ready. Project membership remains the access boundary; knowing a workflow or project identifier is not sufficient authorization.

Retrying coordination is not the same as retrying an effect

Retries are useful for transient failures, but an external action needs special care. If a provider accepted a request before a connection failed, blindly repeating it can duplicate the effect. Durable orchestration does not automatically make arbitrary third-party actions exactly once.

The practical design is to keep stable identifiers, record the product state, use provider idempotency where supported and preserve the review boundary around external actions. The exact handling depends on the workflow and provider.

Let sandboxes end without losing the work

E2B gives a run an isolated environment, but a sandbox should not be the only copy of an output. Research notes, drafts and reports need to remain available when that environment is gone. Tin keeps artifacts in project repositories so another run or agent session can inspect the files later.

That persistence is also useful for review: a person can inspect an actual artifact rather than relying only on a conversational summary of what was produced.

Try the hosted MCP endpoint

For Claude Code, the repository documents this connection command:

claude mcp add --transport http tin https://app.tin.computer/mcp

You will need a Tin account and a project. Individual workflows can also require connected services and credits. Start by inspecting available workflows and their prerequisites before executing anything.

Tin is Apache-2.0 licensed. The hosted app is available at app.tin.computer. Self-hosting currently requires engineering setup and managed-service configuration; the repository is not a turnkey self-hosting package.

If you build durable workflows around coding agents, I’d be interested in how you separate orchestration state, human review and persistent artifacts.

DEV Community: Ege Demir