Building on Zeeren in 2026: Unified MiniApp Provision, Durable Schedules, and the Composable Skills Layer

A quick orientation

Zeeren is an agentic overseas-ops platform. The core abstraction is a Work — a persistent, collaborative context that holds a resource tree, runs agent nodes, and owns schedules, MiniApps, and data assets. Think of it like a long-lived project container that agents can read, write, and schedule work into.

If you're building on top of Zeeren, there are three recent changes worth knowing about.

1. Unified MiniApp provision: one call instead of 14

The old flow (pre-2026-04) required chaining 14 discrete API calls to scaffold a MiniApp — create the record, create the resource tree, link the Work, apply migrations, spin the dev container, and more. Any partial failure left you in an inconsistent state.

The new endpoint, POST /api/v1/miniapps/provision (gated by MINIAPP_UNIFIED_PROVISION=true), wraps the entire transaction. One body, one round-trip:

{
  "slug": "project-tracker",
  "name": "Project Tracker",
  "work_id": 5821,
  "stack": {
    "frontend": "react",
    "backend": "python-fastapi",
    "runtime": "docker"
  },
  "data_mode": "tenant_db",
  "schema": {
    "tables": [
      {
        "name": "projects",
        "columns": [
          { "name": "name",   "type": "text",  "nullable": false },
          { "name": "status", "type": "text",  "default": "'open'" },
          { "name": "owner",  "type": "text" }
        ]
      }
    ]
  },
  "scope": "tenant",
  "visibility": "private"
}

The response comes back with the dev container's host_port, a live preview_url, and the materialised workdir path — everything you need to start generating code immediately.

A few sharp edges worth knowing:

• SLUG_CONFLICT (409): append -N and retry once. The platform won't do this for you.
• provision_failed (500): the transaction rolled back cleanly. Same body is safe to retry.
• WORK_ALREADY_AUTHORING (409): don't retry — the Work already has a MiniApp. Call /miniapps/{id}/status to find where to resume.
• The platform auto-adds id, created_at, updated_at. Don't declare them; you'll get a 422.

The legacy 14-action surface still exists for Works provisioned before April 2026, but new Works should use the unified endpoint.

2. WorkSchedules with multi-trigger support

Scheduling in Zeeren is handled through WorkSchedule records. What's useful is the range of trigger_type options — it's not just cron:

The execution_mode field controls whether each fire opens a new Work (NEW_WORK) or appends a node to the existing one (APPEND_NODE). The latter is the right default when you want the schedule's output to stay in the same conversational context as the Work that owns it.

A minimal CRON body:

{
  "owner_scope": "USER",
  "owner_work_id": 653,
  "name": "Daily standup digest",
  "trigger_type": "CRON",
  "trigger_config": { "cron": "0 9 * * 1-5" },
  "execution_mode": "APPEND_NODE",
  "payload_template": "Generate today's standup digest.",
  "is_active": true
}

For WEBHOOK triggers, the 201 response includes an hmac_secret_plaintext that is not retrievable later. Store it on creation.

3. The skills layer: composable, declarative, skill-card-driven

The thing that ties Work + MiniApp + Schedule together is the skills layer. A skill is a declarative unit (SKILL.md + optional scripts) that defines inputs, outputs, estimated cost, and a procedure for an agent to follow. Skills compose: a meta-skill like zeeren-overseas-retention calls zeeren-goal-decomposer, which fans out into content, concern-triage, and attribution skills.

From a developer perspective, a skill card looks like:

inputs:
  - name: brief
    type: string
    required: true
outputs:
  - name: channel_drafts
    output_type: draft_action
    action_type: "publish_<channel>_post"
estimated_cost_usd: 0.12
estimated_duration_seconds: 45

Skills target either a WORK_DOMAIN agent (flexible reasoning, tool access) or a deterministic SKILL runner (fixed procedure, no LLM calls beyond the skill's own prompts). Schedules can invoke either.

The skill model makes it straightforward to build reliable automated workflows without wiring together microservices — the platform handles routing, retries, and output persistence into the Work's resource tree.

Getting started

The three moving parts — Works, MiniApps, and Schedules — are enough to build most internal tooling. Start with the unified provision endpoint to scaffold your app, use APPEND_NODE schedules to run recurring tasks inside the same Work context, and use skill cards to define the agent procedures your schedules will invoke.

The legacy 14-action surface is still there if you're maintaining an older Work, but new development should default to the unified API.