Bezel Workflow runtime-boundary-spec
runtime-boundary-spec artifact · for Bezel Workflow · status draft
runtime-boundary-spec artifact · for Bezel Workflow · status draft
No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.
Build Bezel Workflow and Bezel API in the same repo/build stream while preserving separate human-product and agent-runtime layers.
Machine-readable source fields
runtime-boundary-spec
/Users/justinking/Vaults/Projects/bezel-api
Bezel Workflow
Build Bezel Workflow and Bezel API in the same repo/build stream while preserving separate human-product and agent-runtime layers.
atlas-codex
2026-05-09T13:17:30.522Z
Hosted/multi-tenant behavior should use Bezel API routes and database/HCS boundaries. Local behavior can bypass hosted network calls only behind an adapter that implements the same contract.
| owns | layer | audience | must not own |
|---|---|---|---|
| - Flow builder - workflow templates - connector configuration UX - credential setup UX - manual/test execution UX - run timeline - failure remediation views - approval/policy controls | Bezel Workflow Product | humans building and operating automations | - claim arbitration internals - raw HCS message writing - agent API-key auth semantics - low-level task graph authoring as primary UX |
| - FLOW.json schema - connector manifest schema - credential reference schema - run event schema - step output/error contracts - flow-to-plan compiler contract | Workflow Contracts | both product compiler and runtime | - browser UI - database-specific SQL - hosted-only assumptions |
| - workspace tenancy - roles - queues - agents - workflow_definitions - workflow_runs - tasks - task_dependencies - task_claims - claim lifecycle - workflow event reads - Lite HCS claim proofs | Bezel API Runtime | agents and runtime clients | - human visual builder decisions - marketing/product positioning - manual canvas editing behavior |
| - connector action manifests - trigger adapters - OAuth/API credential resolution - response normalization - self-healing policy execution - structured completion payloads | Connector Runtime | agents executing integration work | - raw permanent credential storage in workflow rows - unbounded autonomous code changes without policy |
n8n main receives triggers/webhooks, creates workflow executions, Redis queues execution IDs, and workers pull whole executions.
Bezel queues claimable work by role/topic/step; agents pull according to capacity; Router/Flow Engine consumes structured completions and dispatches next work.
- A Flow can compile to today’s PlanIntake-like task graph without UI-specific fields leaking into runtime tasks.
- A run timeline can render from sanitized workflow events without reading task input payloads.
- A connector action can execute locally and hosted through the same manifest/action contract.
- A credential reference can be resolved locally or hosted without changing FLOW.json.
runtime-boundary.v1
Local dogfooding may call local packages/functions directly or local HTTP endpoints, but product code should preserve the same contracts that hosted Bezel API will consume later.
99edd8d2-5780-43a2-bbd0-03982353768a
3a1bb081-67f9-41ae-9600-a91fbb14ecda