Managing Autonomous Agents with the Open GitAgent Protocol (OpenGAP)
Every team building AI agents eventually runs into the same uncomfortable question: what is the agent, exactly? Is it the system prompt?
The YAML config?
The tool schemas wired into a specific framework? Today the honest answer is usually “all of the above, spread across three files, in a format that only works with the framework we happened to build on.”
That’s fine for a demo. It falls apart the moment you need to move an agent to a different framework, hand it to another team, roll back a bad prompt change, or explain to a compliance officer exactly what changed between last week’s version and this week’s.
Two open-source projects, both from the open-gitagent organization, are worth looking at together because they attack this problem from opposite directions.
OpenGAP asks “what if an agent’s identity was just a Git repo?” ComputerAgent asks “what if the thing that runs an agent didn’t care where the agent came from or what engine it needed?” Neither answer is complete on its own, but put side by side, they sketch a fairly clean separation between defining an agent and operating one.
Part 1: OpenGAP’s core idea: treat the agent like source code
The thought process behind OpenGAP starts from something developers already trust: Git. We already use it to track changes to code, review changes before they ship, branch experimental work safely, and roll back when something breaks.
OpenGAP’s bet is that agent behavior deserves exactly the same discipline, so instead of inventing a new versioning system for prompts, it doesn’t. It stores an agent’s identity as files in a repo, spec version 0.1.0, and lets Git do what it already does well.
Concretely, a minimal viable agent is two files:
Everything else is optional structure that a repo grows into as needed:
- skills/: capability modules, each a SKILL.md plus scripts
- tools/: MCP-compatible tool schemas
- workflows/: deterministic multi-step chains
- knowledge/: reference docs, embeddings-based entity trees
- memory/runtime/: persistent state written across sessions, like dailylog.md and context.md
- hooks/: lifecycle handlers (bootstrap.md/teardown.md)
- agents/: for composing sub-agents recursively
A CLI ties it together: opengap init –template {minimal|standard|full}, opengap validate, opengap export –format <adapter>, opengap run <dir> –adapter <name>.
A few implications fall out of this file-as-source-of-truth framing that are worth sitting with technically:
1. Diff-ability and rollback are literal, not metaphorical. A prompt regression is just a bad commit against SOUL.md, so git revert becomes your incident response. And opengap validate runs in CI on every push, like a linter would, catching bad changes pre-merge instead of in production.
2. Portability is implemented as adapters, not aspiration. opengap export –format <target> walks the same repo structure and emits framework-native output:
- claude-code → a CLAUDE.md file
- openai → Python SDK boilerplate
- crewai → YAML
- cursor → .cursor/rules/*.mdc files
- copilot → GitHub Copilot instructions
The identity data structure stays constant; only the serialization target changes.
3. Composition works like a package manager. An agent.yaml can declare extends:, pointing at a base agent’s Git URL, and dependencies: with a source, semver version range, and mount path for pulling in sub-agents. For example, mounting a fact-checker agent at agents/fact-checker and inheriting the shared root-level context.md, skills/, and tools/.
Compliance is a schema, not a document. The manifest supports a compliance block:
opengap validate --compliance checks a repo’s compliance block against its actual role assignments in DUTIES.md. Specifically, it looks for maker/checker conflicts, meaning cases where the same agent role both originates a decision and approves it. If that conflict shows up, validation fails and deployment is blocked under enforcement: strict. This maps directly onto real regulatory requirements:
FINRA Rules 3110, 4511, and 2210 around supervision, and Federal Reserve SR 11-7 expectations for model risk management, with audit logging built to be compatible with SEC 17a-4 immutable-storage rules. What makes this different from a compliance policy sitting in a PDF on a shared drive is that the constraint is machine-checked, automatically, against the same repo that actually defines and runs the agent.
The workflow layer (SkillsFlow) applies the same instinct to multi-step processes. Instead of trusting the model to re-derive step order every run, you write it down:
Template variables (${{ steps.lint.outputs.issues }}) pipe outputs between steps explicitly, and depends_on fixes the DAG so execution order is deterministic even though the reasoning inside each step is still LLM-driven.
Computer Agent
ComputerAgent — Decouple Identity from Execution
Part 2: ComputerAgent’s core idea: decouple identity from execution entirely
ComputerAgent starts from a different but complementary observation: even after you nail down what an agent is, you still have to decide where it runs, what drives its reasoning loop, how it persists memory across turns, and how you’ll debug it after the fact. Most frameworks bundle those decisions together too — pick LangChain and you’ve implicitly also picked its execution model and memory approach. ComputerAgent’s design explicitly refuses that coupling by treating a running agent as four independent, swappable axes:
- WHAT: Identity: Who the agent is, handled through a pluggable IdentityLoader interface so different identity sources can be swapped in.
- HOW: Reasoning engine: What actually drives the agent’s thinking. You can choose between:
- @computeragent/engine-claude-agent-sdk — Anthropic’s Claude Agent SDK (the default)
- @computeragent/engine-gitagent — wraps gitclaw, OpenAI-compatible
- A LangGraph DeepAgents driver
- WHERE: Execution environment: Where the agent’s code actually runs, with a trade-off between startup speed and isolation:
- Local subprocess — fastest, ~100ms cold start
- Linux bwrap sandbox — lightweight isolation, ~50ms
- E2B Firecracker microVM — strongest isolation, ~2s, best for untrusted code
- Apple’s VZ virtualization (macOS) — ~3s
- REMEMBER: Session persistence: How conversation/session state is saved, swappable between in-memory, flat file, MongoDB, or SQLite backends, all behind the same interface.
None of these should force your hand on the others, and the mechanism that makes that real is the Harness Protocol: a typed event stream over HTTP + Server-Sent Events between the client SDK and a harness server, carrying events like session-started, permission-requested, usage-snapshot, and session-ended.
Every event is tagged with a protocolVersion, so a client and server that drift out of sync throw an explicit HarnessProtocolError instead of silently misbehaving. Session state itself lives in a per-session ring buffer (1,000 events / 5 minutes by default), and a dropped connection can resume from a Last-Event-ID, the same reconnection pattern used in standard SSE implementations.
At the API surface, instantiating and driving an agent looks like:
The ChatHandle returned by .chat() is dual-interface, iterate the event stream directly for fine-grained control, or just await the final result, and await using gives scope-based cleanup so sandboxes and connections don’t leak.
Observability isn’t an afterthought bolted on for a demo: traces are OpenTelemetry-native, emitting gen_ai.* semantic-convention spans that plug into Honeycomb, Datadog, Grafana, or ClickHouse without a translation layer, and cost/usage is tracked through a UsageRollup abstraction that supports both cumulative and delta cost semantics. Governance follows the same “assume things will go wrong” posture: tool-call gating via permission callbacks or TTY approval prompts, and policy evaluation against Cedar or OPA rulesets that fail closed on a policy-service error rather than fail open.
Why OpenGAP + ComputerAgent Fit Together
Part 3: Why these two ideas fit together
The fit shows up directly in the code.
ComputerAgent’s default IdentityLoader implementation is @computeragent/identity-gitagentprotocol, which resolves a Git URL, checks out the repo, and parses agent.yaml and SOUL.md per the OpenGAP spec into the identity object the harness actually runs. So source: “https://github.com/org/loan-originator.git” from the earlier snippet works with zero adapter code, as long as that repo is OpenGAP-shaped.
ComputerAgent’s own documentation puts it plainly: identity is the “WHAT,” and the default loader is GitAgentProtocol.
On the engine side, @computeragent/engine-gitagent wraps gitclaw from the open-gitagent/gitagent project and adds session-replay-based resume, so a GAP-defined agent running under that engine can be paused and restarted mid-session without losing state, which matters for anything long-running or subject to interruption.
That gives you a genuinely decoupled operational model:
- Changing what the agent believes, knows, or is permitted to do is a pull request against SOUL.md or the compliance block in agent.yaml, reviewed, diffed, revertable, and checked by opengap validate –compliance in CI.
- Changing where or how that same agent executes, swapping runtime: “local” for runtime: “e2b”, swapping memory: “file” for memory: “mongodb”, or pointing OpenTelemetry at a different backend, is just a ComputerAgent constructor argument, and never touches the identity repo at all.
The practical payoff: a segregation-of-duties-enforced lending agent can run as a cheap local subprocess in a dev environment and inside a hardened Firecracker microVM in production, using the same commit hash and same audit trail, because identity and execution were never welded together to begin with.
The bigger idea worth taking away
Most of the friction in productionizing AI agents comes from identity and execution being fused inside one framework’s assumptions, change the prompt and you’re touching the same codebase as the sandbox config and the memory backend.
OpenGAP and ComputerAgent are an argument, made in code rather than a whitepaper, that these are separable concerns with a clean interface between them: a Git repo on one side, an IdentityLoader on the other.
Whether or not either project becomes the standard, that separation, identity as versioned, framework-agnostic data; execution as a swappable runtime around it, is the part worth carrying into how you architect agent infrastructure going forward.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
