Summary
Investigate introducing a second agent runtime kind so an "agent" is no longer necessarily a Docker container running Claude Code. Today every agent is a container (Architectural Invariant #11, "Docker as Source of Truth"). A native, in-process runtime would let purpose-built node types execute custom backend logic — calling the Anthropic SDK directly only for the judgment parts — while reusing the existing agent UX (listing, sharing, access control, channels, operator queue) without per-agent container overhead.
Context
Came out of a design discussion on multi-tenant program management (linked below as the first consumer). For workloads that are mostly deterministic orchestration with occasional LLM judgment, a full Claude Code container per agent is heavy, costly at scale, and drags in slot/heartbeat/stdout-race machinery the work doesn't need. A runtime seam would concentrate that complexity in one tested engine and open the door to future native node types (deterministic routers, webhook processors, aggregators).
The principle that keeps it sane: Trinity owns identity + state + scheduling + delivery; the runtime owns judgment. A native runtime stores its state in the DB and survives reset/redeploy/deletion.
Acceptance Criteria (research deliverables)
Technical Notes
Summary
Investigate introducing a second agent runtime kind so an "agent" is no longer necessarily a Docker container running Claude Code. Today every agent is a container (Architectural Invariant #11, "Docker as Source of Truth"). A native, in-process runtime would let purpose-built node types execute custom backend logic — calling the Anthropic SDK directly only for the judgment parts — while reusing the existing agent UX (listing, sharing, access control, channels, operator queue) without per-agent container overhead.
Context
Came out of a design discussion on multi-tenant program management (linked below as the first consumer). For workloads that are mostly deterministic orchestration with occasional LLM judgment, a full Claude Code container per agent is heavy, costly at scale, and drags in slot/heartbeat/stdout-race machinery the work doesn't need. A runtime seam would concentrate that complexity in one tested engine and open the door to future native node types (deterministic routers, webhook processors, aggregators).
The principle that keeps it sane: Trinity owns identity + state + scheduling + delivery; the runtime owns judgment. A native runtime stores its state in the DB and survives reset/redeploy/deletion.
Acceptance Criteria (research deliverables)
execute/start/stop/status/capabilities) and where it slots behindtask_execution_service/agent_clientruntime_kindmodel: schema change toagent_ownership(claude_code|native), defaultclaude_code; impact onlist_all_agents_fast(must union Docker-labeled agents + DB-native rows)docker_serviceusage, lifecycle, logs/stats/files/ssh/git) and how each is guarded onruntime_kindor routed through the runtime interfaceTechnical Notes
src/backend/services/task_execution_service.pyandsrc/backend/services/agent_client.pysrc/backend/db/schema.py+src/backend/db/migrations.pyregister_enterpriseseam (Spike: enterprise edition architecture — private module strategy for compliance features (SSO, SCIM, SIEM) #847)docs/memory/architecture.md