System architecture

Connections, control, and management.

JIMJAM'EST is not a chat shell. It is a control plane for agents that finish internal workflows: declare what they can reach, decide who may act, then manage the queue, exceptions, and evidence.

01

What can the system reach?

Connections

External systems and internal integration points agents use to act outside the app boundary.

  • Connectors

    0 enabled

    0

  • Commercial edge

    Checkout · portal · webhooks

    Stripe

  • Dispatcher

    Claims queued runs

    External

02

Who decides and who may act?

Control

Identity, agent intent, enablement, and policy gates that authorize work before it is queued.

  • Agents

    Intent + strategy

    0

  • Auth boundary

    Supabase SSR session

    Email/password

  • Data plane

    Owner-scoped policies

    RLS

03

How is work owned and observed?

Management

Queues, run history, operator work items, billing, and signals used to steer live automation.

  • Open runs

    0 total runs

    0

  • Work queue

    0 active/blocked

    0

  • Observation

    Append-only trails

    Logs + signals

Topology

How authority moves

Operators configure the left side. Policy sits in the middle. Management surfaces on the right stay readable even when a dispatcher is still offline.

Connections feed control, which queues managed runsCONNECTIONSCONTROLMANAGEMENTConnectorswebhook · API · databaseStripe billingcommercial boundaryDispatcherexternal workerAuth + RLSowner scope gateAgentspurpose · strategy · statusqueue_execution_runenabled-connector RPCRuns + logsdurable queue + trailWork queuerecords + activitySignalscadence + streaks

Control flow

Request path to managed work

  1. 01

    Declare connections

    Operators register connectors with a type and enablement flag. Nothing external is reachable until it exists here.

    Open surface
  2. 02

    Define control

    Agents capture purpose and connector strategy. Auth plus RLS decide who may create or change them.

    Open surface
  3. 03

    Queue under policy

    queue_execution_run verifies the caller owns an enabled connector, then inserts a durable queued run.

    Open surface
  4. 04

    Dispatch and manage

    An external dispatcher executes side effects, writes logs, and closes the run. Humans manage exceptions in the work queue.

    Open surface

Component catalogue

What owns what

Connections

  • Execution connectors

    Declared outbound paths: webhook, API, database, or custom connector types.

    Edge
    Owns
    Enabled integration endpoints
    Schema
    execution_connectors
    Open Execution connectors
  • External dispatcher

    Worker outside the request path. Claims queued runs, talks to connectors, writes results.

    Runtime
    Owns
    Actual side effects
  • Stripe billing

    Subscription and usage commercial boundary via checkout, portal, and webhooks.

    Edge
    Owns
    Entitlements and invoices
    Open Stripe billing

Control

  • Next.js control plane

    Authenticated product UI and server actions for operators and builders.

    Surface
    Owns
    Routes, forms, session-bound mutations
    Open Next.js control plane
  • Supabase Auth

    Email/password identity. Every owner-scoped table keys off auth.uid().

    Policy
    Owns
    Session cookies, user identity
  • Orchestration agents

    Named agents with purpose, connector strategy, and lifecycle status.

    Runtime
    Owns
    Intent and strategy, not execution
    Schema
    orchestration_agents
    Open Orchestration agents
  • queue_execution_run

    Security-definer RPC that only queues runs for the caller’s enabled connectors.

    Policy
    Owns
    Write gate into the run queue
    Schema
    queue_execution_run()
  • Row-level security

    Owner policies keep agents, connectors, runs, and records private per user.

    Policy
    Owns
    Tenant isolation at the data plane

Management

  • Execution runs

    Durable queue rows. Authenticated users can read; workers write lifecycle updates.

    Store
    Owns
    queued → running → terminal state
    Schema
    execution_runs
    Open Execution runs
  • Run logs

    Append-only operator-visible trail for each run.

    Store
    Owns
    info / warning / error messages
    Schema
    execution_run_logs
    Open Run logs
  • Workflow records

    Human-owned work queue with explicit status transitions and activity history.

    Store
    Owns
    draft → active → blocked → done
    Schema
    workflow_records
    Open Workflow records
  • Record activity

    Append-only audit of creates, field edits, status changes, and notes.

    Store
    Owns
    Operator audit trail
    Schema
    workflow_record_activity
  • Progress signals

    Daily check-ins and streaks for reliability habits around live workflows.

    Store
    Owns
    Operational cadence
    Schema
    tracking_items / daily_tracking_entries
    Open Progress signals

Infrastructure boundary

Managed stack this map assumes

Product UI on Vercel. Data, auth, and RPCs on Supabase. Commercial edge on Stripe. Run execution is intentionally outside the request path so the control plane stays durable when workers scale independently.

App
Next.js 16 · Bun · React 19
Data / auth
Supabase Postgres + RLS
Billing
Stripe webhooks
Hosting
Vercel staging / prod