Horizon takes requests and external events into remote coding sessions, connects them to company context through MCP, and returns changes for human review. Its orchestrator manages sandbox lifecycle and routes results back to Slack, Linear, GitHub, or the web UI.
Delegated Linear project to merged, human-approved pull requests across the dependency chain.
Divide the project into issues
The PM agent splits a delegated Linear project into individual issues with descriptions and dependency ordering; a human reviews each issue before implementation starts[Source 1]
Run the implementation session in the sandbox
When an issue moves to In Progress, the orchestrator assigns it to a cloud agent that boots the Docker development container with OpenCode and the custom MCP context server[Source 1]
Hand off the pull request for human review
The run ends as a pull request attributed to the issue owner; no code merges without explicit human approval[Source 1]
Continue the dependency chain after merge
The GitHub merge webhook marks the Linear issues done and starts the next eligible run on newly unblocked issues[Source 1]
Where people stay involved
People review, approve, or guide the agent’s work here.
Reported: A human reviews each PM-generated issue before implementation starts, and a human is always in the loop at pull-request handoff; humans are frequently the bottleneck.
Supervision level
Work-product review
A person reviews the draft or implementation.
3/5Level 3 of 5
requirements and acceptance criteria → tested implementation[Source 1]
Not reportedNo source names the underlying model; the harness is the swappable layer (OpenCode in the core article, Claude Remote Routines in the showcase).
Harness
Modular by design; the core article runs OpenCode in the sandbox; the Applied AI Showcase runs Claude Remote Routines. The harness is swappable as agent tech changes; separate PM, implementation, and prospective verification/security roles[Source 1, Source 2]
Sandbox
Cloudflare Containers + Sandbox SDK; disposable, tightly scoped sandboxes with explicit lifecycle APIs and egress controls; full monorepo stack in Docker dev containers[Source 1]
Tool access
A custom MCP server stitches internal data sources (Datadog, Sentry, Slack, WorkOS Pipes); all outbound traffic proxied through Workers with allowlists, limits, logging, and token injection[Source 1, Source 2]
Knowledge
AGENTS.md and CLAUDE.md capture scripts, docs, conventions; MCP codifies the patterns engineers already follow; Notion + Figma for specs/mockups[Source 1]
Context management
The orchestrator pauses/resumes sandboxes and tracks state + artifacts across a run[Source 1]
Credentials
WorkOS Pipes (no OAuth/token-refresh to maintain); scoped short-lived GitHub tokens per user; engineers use their own identity in the MCP; least-privilege + egress controls[Source 1]
Sandbox = execution primitive vs orchestrator = control plane
An orchestrator outside the sandbox manages requests, lifecycle, and returned artifacts[Source 1]
Purpose-built agent infra
Cloudflare sandbox infrastructure with programmatic lifecycle APIs and an outbound proxy for egress controls[Source 1]
Self-improvement loop
Session logs can lead to proposed fixes, scripts, or context updates; many platform tasks are still seeded manually[Source 1]
MCP as an iterative product
WorkOS revises tool names and schemas to address repeated exploration and mistaken tool use[Source 1]
Validation and failure handling
Verify the work inside the sandbox
The run lints, builds, and runs automated tests, and does initial validation of acceptance criteria, before requesting human attention[Source 1]
Reported observations
Not reported: The captures describe capability and direction without a measured Horizon outcome; the UI Nits closure rate belongs to the surrounding program rather than to Horizon alone.
Lessons
WorkOS chose Cloudflare sandbox infrastructure for programmatic lifecycle control and an outbound proxy that enforces its egress policy.[Source 1]
Horizon's orchestrator runs outside disposable sandboxes and manages incoming work, sandbox lifecycle, and returned artifacts.[Source 1]
Catalog interpretation: WorkOS describes OpenCode in one Horizon deployment and Claude Remote Routines in another; the accounts do not establish a migration of the whole platform.[Source 1, Source 2]
Horizon turns run friction into proposed platform fixes, while WorkOS still seeds many improvement tasks manually and retains human review.[Source 1]
WorkOS revises MCP tool names, schemas, and conventions after observing agents repeat expensive exploration and wrong turns.[Source 1]
Reported: A human reviews each PM-generated issue before implementation starts, and a human is always in the loop at pull-request handoff; humans are frequently the bottleneck.
implementation
Reported
validation
Reported: Lint, build, and automated tests run in the sandbox before human attention; headless browser verification is named as planned work, not a current check.
observations
Not reported: The captures describe capability and direction without a measured Horizon outcome; the UI Nits closure rate belongs to the surrounding program rather than to Horizon alone.
The architecture post supports modular components and the showcase names a different engine, but neither describes a complete before-and-after migration.
The feedback-loop section describes log-driven fixes and explicitly limits the degree of automatic task creation; it does not measure continual reliability gains.
The source states a human is always in the loop at PR handoff and no code merges without explicit human approval; humans also review each PM-generated issue before implementation starts.
