Skip to content

DecapodLabs/accountable-agentic-execution

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

77 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Accountable Agentic Execution

Research paper and executable evaluation program investigating individual-agent alignment and heterogeneous fleet coherence through Intent, Custody, Trajectory, and Proof.

Status: Pre-results technical report. The model, terminology, paper, and reproducibility harness are public. The empirical benchmark has not yet been executed. Checked-in run records and aggregate values are synthetic harness fixtures, not observations; no treatment effect or performance claim should be inferred from them.


LaTeX Compilation 🦀 Decapod Artifact Project Page License: MIT


1. Executive Summary

As Large Language Model (LLM) coding agents transition from passive completion assistants to autonomous, tool-using executors, their operations resemble concurrent processes running over a mutable repository space. Many workflows still rely heavily on conversational transcripts and code diffs as durable records; that baseline does not by itself preserve authority, ownership, cross-session continuity, or machine-checkable completion evidence.

This repository hosts the LaTeX source and reproducible evaluation harness for our paper: "Intent, Custody, Trajectory, and Proof: Toward Accountable Execution in Agentic Software Engineering."

We formalize four core primitives to achieve accountable agentic execution:

  • Intent: The human or team’s desired outcome, motivation, constraints, priorities, unresolved questions, and standard of completion, progressively represented across governed artifacts.
  • Custody: Governed task ownership and isolated git-worktree or configured container boundaries within which the agent operates.
  • Trajectory: Event-backed records of selected task, broker, proof, memory, and governance activity that can be rendered as a flight-recorder timeline.
  • Proof: Programmatically checkable validation, proof-run, workunit, and provenance evidence for a governed workspace state.

This artifact is designed to evaluate these primitives using Decapod, a daemonless, local-first governance kernel that coordinates intent, task custody, validation, proof events, and publication around existing coding agents. The primary empirical question remains whether one complex natural outcome-oriented request can support “type the outcome and walk away”: Decapod resolves authoritative project context before implementation inference, while the underlying model remains unchanged.

The expanded research program also tests fleet coherence: whether independently launched agents can use durable project authority, task ownership, selected trajectory, and shared proof to hand work across sessions/workbenches and execute concurrently with less reconstruction, duplication, and integration waste. Fleet coherence is an emergent property of the four primitives, not a fifth primitive or a claim of global consensus. The human speaks naturally to the available agent; the agent handles Decapod's stable governance protocol.

The central fleet-coherence question is: 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? Worktrees alone answer only the direct-mutation part of that question; the prospective fleet study also measures duplicate inference, semantic overlap, dependency violations, merge and integration repair, and proof after combination.

Decapod is offered as a candidate agent-governance interoperability profile: a standard agent-callable component that coding-agent harnesses could pre-bundle or discover. The goal is a narrow machine contract for authority, task custody, selected trajectory, and proof so users and agents can move fluidly among Claude, Codex, Antigravity, Grok, and other conforming harnesses without making one vendor conversation the project's durable state. This is a standards direction inspired by MCP and A2A and by the layered, independently implementable interfaces of HTTP and IP—not a claim that Decapod is already an adopted standard, native MCP/A2A implementation, HTTP service, or vendor-bundled component. The current implementation is a daemonless local CLI plus a Decapod-specific structured process RPC. See the interoperability profile and implementation roadmap.

The constitution is the authority root for that contract. Decapod currently embeds a structured baseline constitution in the binary and supports a binding project-local override; task-scoped context resolution selects provenance-bearing projections before inference. An organization-level overlay is planned but not implemented at the inspected revision. This design is the author's response to repository-instruction poisoning: authority, scope, selection, and proof expectations should be explicit rather than treating any large instruction file as automatically trustworthy. The author coined Intent-Driven Design as the name of this software-engineering approach in public LinkedIn posts beginning in August 2025 and, by September 2025, was using a constitution to scaffold project boilerplate and derived agent guidance. This lineage predates and arose independently of the February 2026 ETH Zurich preprint; it does not establish empirical efficacy.

The implementation mapping is pinned to Decapod 207e9a3 (v0.66.3). It verifies real task claims, trust-gated handoff, workspaces, context capsules, repository memory, governance events, proofs, and publication gates. It also records narrower boundaries: shared ownership exists, handoff does not transfer hidden conversation state, worktrees do not guarantee clean integration, and the public cloud backend is unavailable. The intervening changes from the prior v0.66.1 audit are release, CI, and research-link documentation changes; mapped implementation paths are unchanged.

Study A is the primary walk-away CN-versus-DN comparison. Prospective Studies B–D cover handoff continuity, concurrent fleets, and tool switching. Study E is a separately labeled longitudinal case study: an older checked-in snapshot at e7df80d records 2,127 commits and 326 tags between February and July 2026, but those facts do not establish a causal effect or low review burden. No controlled fleet results exist. The project does not claim complete OS-level sandboxing, credential isolation, universal action interception, conflict-free merging, or signed completion certificates.

The protocol is not frozen. As Decapod develops, the prospective experiments, hypotheses, conditions, instrumentation, and sample plan may change to track the mechanisms actually implemented. Pre-freeze changes are versioned and explained; after freeze, material changes require a new protocol version or a disclosed deviation rather than silent revision.

Public adoption is ecological context, not performance evidence. A July 13, 2026 API snapshot reported 222 GitHub stars, 21 forks, and 6,983 crates.io downloads—approximately 7,000 downloads, but not more than 7,000 in that query. These counts do not establish correct use, interoperability, or a treatment effect.

Decapod is used across 18 repositories in three owner namespaces—15 public and three private:

The alexhraber/alexhraber repository is the author's public researcher and engineer profile. The worldofgeese maintainer discovered and adopted Decapod independently; the remaining 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. See the repository-use inventory.

The author reports running decapod init once when establishing each repository, before the first agent interaction or other engineering operation. After that one-time bootstrap, the human interacts naturally with agents and the generated AGENTS.md contract requires the agents to use Decapod continuously at governance boundaries. The inventory is consistent with that practice; it does not independently prove compliance or effectiveness.

Decapod has aided this paper and executable research artifact since their inception. That reflexive dogfooding is visible through the repository's governed specifications, tasks, workspaces, validation, and proof surfaces; it is implementation experience, not independent validation.


2. Directory Layout

The workspace is organized to keep paper drafts, empirical records, and system documentation strictly partitioned:

├── paper/                 # LaTeX paper sources and bibtex citations
│   ├── sections/          # Draft files for sections 01-09
│   ├── figures/           # Plot files and diagram vectors
│   └── tables/            # Evaluator-generated LaTeX table inputs
├── artifact/              # Reproducible experiment package
│   ├── tasks/             # Task-package contract + one non-empirical fixture; target suite is 35
│   ├── baselines/         # Execution traces for prompt & checklist baselines
│   ├── decapod-runs/      # Execution traces under Decapod governance
│   ├── scripts/           # Execution and metrics collation scripts
│   ├── fixtures/          # Synthetic schema fixtures, never empirical evidence
│   ├── observational/     # Separately bounded longitudinal repository facts
│   └── results/           # Processed synthetic summary data and future generators
├── docs/                  # Design registers, publications logs, and taxonomy
│   ├── research-claim.md  # Main claims and falsifiable predictions
│   ├── experiment-plan.md # Metric definitions and experimental layout
│   ├── fleet-coherence-protocol.md # Prospective handoff/concurrency/tool-switch studies
│   ├── agent-governance-interoperability.md # Candidate thin-waist profile and implementation roadmap
│   ├── adoption-inventory.md # Verified repository markers and ecological-evidence boundary
│   ├── implementation-claim-matrix.md # Decapod code/test support and boundaries
│   └── terminology.md     # Project taxonomy and definitions
└── pages/                 # Web landing page and metrics dashboard

3. Getting Started

Important

To compile the LaTeX draft or execute the verification scripts, you must install the required system dependencies:

sudo apt-get update && sudo apt-get install -y build-essential latexmk texlive-latex-extra git python3

Building the Paper

To build the LaTeX source document to a compiled PDF locally:

make paper

To check directory layout integrity and list system dependencies:

make check

To clean build files:

make clean

Running the Artifact

Please refer to the reproducibility guide inside the artifact/ directory for instructions on executing baseline agents, running the Decapod governance kernel, and regenerating the statistical plots shown in the paper.

About

Accountable execution primitives for agentic software engineering: Intent, Custody, Trajectory, and Proof. Evaluates the Decapod governance kernel.

Resources

License

Stars

2 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors