Projects

The Projects page at Dashboard → Projects is where pipeline-driven work lives. A project is a sequence of agent invocations strung together by a template — research, storyboard, scaffold, scene work, render — with checkpoints between steps.

Where a run is one shot at one agent, a project is a whole campaign. The same input can drive a 20-subtask, multi-agent, multi-hour effort with backtracking, dynamic re-planning, and per-step approval.

When to use a project

Use a project when:

  • The work decomposes into named steps (research → plan → execute).
  • Different steps want different agents (Fumi for research, Sai for scene work).
  • You want checkpoints — approve a storyboard before scaffolding.
  • You want recoverable state — pause and resume, retry a failing subtask, backtrack with cascade invalidation.

If you just want one agent to answer one question, invoke the agent directly. Save projects for sustained work.

Project templates

The available templates are defined in ~/.workflows/pipelines/registry.json and surfaced at Dashboard → Projects → New. The canonical templates:

Template What it does
content Full content pipeline: idea → research → storyboard → scaffold → character setup → per-scene pipeline → summary.
research Standalone research project (Fumi-led, with citation rollup).
micro-saas The MS pipeline — ship a feature into one of the Forjio family products with the deploy gates baked in.
agent-build Build a new agent from a brief: persona, tool budget, taste rules, test prompts.

New templates land via the runtime repo; the portal lists whatever the registry exposes.

Starting a project

From Dashboard → Projects, click New project:

  1. Pick a template.
  2. Fill in the brief (template-specific — usually a free-form description plus a few key fields).
  3. Optionally attach files or URLs as context.
  4. Click Start.

The portal POSTs to /v1/projects with the template slug and the brief. The runtime acknowledges, plans the initial task tree, and the page switches to the project detail view.

The same call via SDK:

const project = await catentio.projects.create({
  template: 'content',
  brief: { topic: 'Sustainable urban farming', tone: 'practical' },
});

The project detail page

The detail page is the dashboard's most information-dense surface. Sections:

Project ID, template, current state (running / paused / succeeded / failed / abandoned), elapsed time, total cost so far.

Action buttons: Pause, Resume, Abandon, Run next step (manual override).

Task tree

A hierarchical view of tasks → subtasks. Each row shows status, the agent assigned, the latest attempt, and a click-through to the subtask detail.

Dynamic re-planning shows up live: if a running subtask emits a replan block, new subtasks insert themselves into the tree as the runner reads them.

Attempts

For any subtask, click into it to see every attempt. Failed attempts preserve their output for inspection; the Retry button kicks a new attempt that takes the latest plan as input.

Artifacts

Files, screenshots, JSON payloads — anything the runtime's output_artifact tool wrote during the project. Each artifact links back to the subtask that produced it.

Events

A flat timeline of outbox events: state transitions, subtask completions, approval requests, retries. Useful for understanding why the project did what it did.

Cost

Per-subtask and per-agent breakdown, with a running total. Cost is updated live as subtasks complete.

Approval gates

Some steps in some templates are approval-gated — the storyboard step in the content pipeline is the canonical example. When the project reaches a gate, it pauses and the portal raises an approval card on the project detail page:

[Storyboard ready for review]
  → 18 scenes, 4 characters, 12 locations
  ▸ Approve   ▸ Request revision   ▸ Reject

Approve unblocks the runner; Request revision sends the storyboard back to Fumi with your feedback; Reject abandons the project.

In autonomous mode, the taste-learning system can auto-approve based on accumulated confidence. See the catentio architecture repo for the autonomous-mode spec.

Pause, resume, abandon

  • Pause — sends a stop signal. The currently-running subtask completes, then the runner halts. State runningpaused. Resume any time.
  • Resume — picks up from the next pending subtask. State pausedrunning.
  • Abandon — terminal. No way to resume. Use when the project's premise is wrong and you don't want it to keep accumulating cost.

Backtracking

For long projects that go sideways at step 7, you can backtrack to an earlier checkpoint:

  1. Open the subtask you want to roll back to.
  2. Click Backtrack here.
  3. Confirm.

The runner cascades invalidation forward — every subtask after the target marked as superseded — and re-plans from the target.

Per-project cost limits

Each project has an optional budget that caps total spend. Hit the cap and the runner auto-pauses with state paused, reason: budget_exceeded. Raise the budget and resume, or abandon.

Budgets are configured in the project's brief (budget_usd) or via API:

catentio-saas projects create --template content --budget 50 --brief @brief.json

Coming features

  • Per-template parameter forms — structured inputs instead of free-form brief blobs.
  • Bulk projects — fan out a single brief into N parallel projects with different variations.
  • Project templates as code — author new templates from the portal (today they live in the runtime).

Next