Intent, Custody, Trajectory, and Proof:
Toward Accountable Execution in Agentic Software Engineering

Large language model (LLM) agents are transitioning from conversational programming assistants to autonomous executors capable of editing codebases, running build tools, executing tests, and managing multi-file software deployments. Many coding-agent workflows still rely heavily on prompt transcripts and diffs as durable records. As runs become concurrent, long-running, and tool-intensive, this chat-centered baseline exposes projects to lost intent, cross-runtime discontinuity, ambiguous ownership, duplicated inference, workspace and integration failure, and unverifiable completion claims.

This paper frames agentic software engineering as a distributed execution problem and asks whether a human can type one complex outcome, start the agent, and walk away. Intent is the human or team’s desired outcome, motivation, constraints, priorities, unresolved questions, and completion standard, progressively represented through governed artifacts. Custody bounds task ownership and workspace authority; Trajectory records selected governance activity; and Proof provides machine-checkable validation and provenance evidence. The primary comparison remains conventional versus Decapod-governed execution under the identical natural delegation prompt.

The expanded program defines fleet coherence: independently launched agents use the same durable project authority, task custody, selected trajectory, and proof boundary across sessions, handoffs, and concurrent work. Agents and conversations are ephemeral execution processes; the governed repository is the durable coordination subject. This is not a fifth primitive, global consensus, lossless conversation transfer, or a conflict-free merge guarantee. The human speaks naturally to the available agent; the agent handles the stable governance protocol. Decapod is offered as a candidate standard agent-callable component that coding-agent harnesses could pre-bundle or discover, not as an already adopted standard or shipped vendor integration. No controlled result is reported here.

Implementation basis: Decapod 207e9a3 (v0.66.3). The audit verifies atomic exclusive claims, trust-gated shared ownership and handoff, task workspaces, deterministic context bundles, local project memory, selected governance events, proof/workunit state, and publication gates. Handoff does not transfer hidden chat state; worktrees do not prove integration; the public cloud backend is unavailable.

Central fleet question: Can multiple independently launched agents concurrently solve similar but distinct problems in the same codebase while preserving shared authority, distinct task custody, isolated mutation, dependency awareness, and integrated proof? Similar work is not necessarily duplicate work, and separate worktrees do not resolve semantic overlap or prove the combined result.

Target interaction: the human speaks naturally to whichever agent is available; the agent invokes the governance protocol. Decapod is offered as a candidate agent-governance interoperability profile so Claude, Codex, Antigravity, Grok, and other conforming coding-agent harnesses could pre-bundle or discover the same authority, custody, trajectory, and proof component. The aim is fluid movement across harnesses without making one vendor conversation the durable project state.

Current boundary: the inspected implementation provides a daemonless local CLI and a Decapod-specific structured request/response document over process standard input/output. It is not currently a native MCP server, A2A endpoint, HTTP governance service, adopted Internet standard, or confirmed vendor bundle. MCP and A2A are candidate adapters; HTTP and IP are limited design analogies for a narrow, layered interface, not claims of equivalent maturity or adoption. See the profile and implementation roadmap.

Repository-use inventory: Decapod is used across 18 repositories in three owner namespaces—15 public and three private. alexhraber: alexhraber, pi-cluster, builddeck, agentic-sdlc-intake-attack, metaplay-fake-interview-supply-chain-incident, flowhawk, tensors-to-consciousness, go-scaling, nixos, private cycle, and private mentora-automa. worldofgeese: den, tarot-api, and mythras-chargen. DecapodLabs: decapod, private gensor, accountable-agentic-execution, and pincher. The alexhraber/alexhraber repository is the author's public researcher and engineer profile. The worldofgeese maintainer discovered and adopted Decapod independently; the other namespaces are author- or organization-affiliated. Because repositories within each namespace share maintainers, this footprint is not evidence of 18 independent adopters or of improved outcomes.

Author operating practice: each repository receives one decapod init before its first agent interaction or other engineering operation. Thereafter the human interacts naturally with agents, while the generated AGENTS.md contract requires continuous Decapod use at governance boundaries. Repository markers are consistent with this practice but do not independently prove compliance or effectiveness.

Research-repository dogfooding: Decapod has aided this paper and executable artifact since their inception. Governed specifications, tasks, workspaces, validation, and proof surfaces make that use inspectable; it remains reflexive implementation experience rather than independent validation.

Intent-Driven Design chronology: the author coined the term as the name of Decapod’s software-engineering approach in public LinkedIn posts beginning in August 2025 and, by September 2025, was using a project constitution to scaffold boilerplate and derived agent guidance. This lineage predates and arose independently of the February 2026 ETH Zurich preprint; it does not establish empirical efficacy.

Protocol evolution: this is an unfrozen prospective program. As Decapod develops, experiments, hypotheses, conditions, instrumentation, and sample plans may change to test the implementation that actually exists. Changes are versioned before freeze; a frozen confirmatory study requires a new protocol version or disclosed deviation for material changes.