Most agent frameworks assume a single orchestrator dispatching tasks to subordinate agents. Covenant Terminal flips this model: it’s a jobs board where agents post work, discover services, and negotiate terms with other agents. The shift from hub-and-spoke to peer-to-peer coordination exposes primitives that don’t exist in current tooling: capability attestation, partial completion handoff, settlement without escrow, and discovery without central indexing.
The project calls itself “Hari’s List,” a marketplace where agents and humans advertise services, agree on price and deadline, and maintain a shared record of delivery and payment. The interesting part is not the UI. It’s the contract layer underneath, the state machine that tracks who owes what when an agent fails halfway through a research brief or a data pipeline.
What the System Does
Covenant Terminal provides:
- Public service listings: agents or humans post what they offer (research, data transformation, API calls).
- Term negotiation: price, deadline, approval authority, and change-request rules are agreed before work starts.
- Shared work record: both parties see delivery status, acceptance, and payment separately, so unfinished work stays visible.
- Agent connection: agents authenticate and claim jobs without manual intervention.
The documentation emphasizes that a payment receipt does not close an unfinished job. This separation of concerns (delivery vs. acceptance vs. payment) is the first primitive most orchestration frameworks skip.
The Missing Primitives
1. Capability Attestation Without Disclosure
An agent needs to prove it can execute a task without revealing its tool implementations or API keys. Traditional auth (OAuth, API tokens) assumes a human or a trusted service. Here, the agent is autonomous and potentially untrusted.
Covenant Terminal does not yet specify a cryptographic attestation protocol, but the problem is clear: how does Agent A verify that Agent B can call the OpenAI API, query a SQL database, and format JSON without Agent B exposing credentials or proprietary logic?
Possible approaches:
- Zero-knowledge proofs: Agent B proves it holds a valid API key without revealing the key.
- Capability tokens: A trusted issuer (or a decentralized registry) signs a claim that Agent B can perform specific operations.
- Execution sandboxes: Agent B runs a test task in a sandboxed environment, and the result is hashed and signed.
None of these are trivial. The system currently relies on manual verification (“confirm a real supplier before ordering”), which works for a demo but breaks at scale.
2. Partial Completion and Handoff
If Agent B fails halfway through a multi-step task, what happens? The options:
- Rollback: Undo all changes and refund the payment. Requires idempotent operations and state snapshots.
- Handoff: Agent C picks up where Agent B left off. Requires a shared state format and a way to resume from a checkpoint.
- Replication: Agent A retries the entire task with Agent D. Wastes compute but avoids coordination overhead.
Covenant Terminal separates delivery, acceptance, and payment, which suggests it supports partial completion. The shared work record tracks what was delivered, even if the job is incomplete. But the documentation does not describe how state is serialized or how a new agent resumes work.
A naive implementation might store task state as JSON in a shared database. A more robust approach would use event sourcing: each step in the task emits an event, and the new agent replays events to rebuild state. This requires agents to agree on an event schema, which is another missing primitive.
3. Payment Settlement Without Escrow
Traditional escrow requires a trusted third party to hold funds until both sides agree the work is done. Covenant Terminal aims for a shared record both sides can reopen, which implies some form of dispute resolution or consensus mechanism.
Options:
- Multisig wallets: Payment requires signatures from both Agent A and Agent B. If they disagree, a third-party arbiter (human or agent) signs.
- Smart contracts: On-chain logic enforces payment rules. High latency and gas costs, but no trusted intermediary.
- Reputation staking: Agents stake tokens or reputation points. If they renege on a deal, they lose the stake.
The current system does not specify a settlement mechanism. The 14-day trial and “fees and access” language suggest a centralized payment processor, which contradicts the peer-to-peer ethos. This is a design tension worth watching.
4. Discovery Without Central Indexing
How does Agent A find Agent B when there are thousands of agents offering similar services? A centralized registry (like a SQL database of service listings) works until it becomes a bottleneck or a single point of failure.
Alternatives:
- Distributed hash tables (DHTs): Agents publish service descriptors to a DHT (like Kademlia). Discovery is O(log N) but requires agents to maintain routing tables.
- Gossip protocols: Agents broadcast service announcements to peers, who forward them. High redundancy, low latency, but chatty.
- Semantic search over embeddings: Service descriptions are embedded as vectors, and agents query a vector database. Requires a shared embedding model and a way to keep the index fresh.
Covenant Terminal uses keyword search (up to eight words), which is simple but fragile. If Agent A searches for “research brief” and Agent B advertises “market analysis,” they won’t match unless someone manually tags them with overlapping keywords.
5. Race Conditions in Bidding
If multiple agents bid on the same task simultaneously, who wins? The system needs a concurrency control mechanism:
- Optimistic locking: Each bid includes a version number. The first bid to commit wins; others retry.
- Pessimistic locking: The task is locked when the first agent starts bidding. Other agents wait or move on.
- Auction protocol: Bids are collected for a fixed time window, then the highest (or lowest) bid wins.
The documentation does not describe a bidding protocol. The “agree before you approve” language suggests a manual negotiation step, which avoids race conditions but does not scale.
Architecture: How It Might Work
Here’s a plausible implementation based on the documentation and common patterns in decentralized systems:
┌─────────────┐
│ Agent A │ (needs research brief)
└──────┬──────┘
│ 1. POST /jobs {"task": "research brief", "budget": 25, "deadline": "Friday"}
▼
┌─────────────────────────────────────────┐
│ Covenant Terminal (API + State Store) │
│ - Job listings (public/private) │
│ - Term agreements (versioned) │
│ - Work records (delivery + payment) │
└──────┬──────────────────────────────────┘
│ 2. Broadcast job to discovery layer
▼
┌─────────────────────────────────────────┐
│ Discovery Layer (DHT or Gossip) │
│ - Agents subscribe to keywords │
│ - Match jobs to capabilities │
└──────┬──────────────────────────────────┘
│ 3. Notify matching agents
▼
┌─────────────┐
│ Agent B │ (offers research services)
└──────┬──────┘
│ 4. GET /jobs/:id, review terms
│ 5. POST /jobs/:id/claim {"agent_id": "B", "signature": "..."}
▼
┌─────────────────────────────────────────┐
│ Term Negotiation (versioned contract) │
│ - Price, deadline, approval rules │
│ - Change requests require re-approval │
└──────┬──────────────────────────────────┘
│ 6. Agent B executes task
│ 7. POST /jobs/:id/deliver {"result": "...", "state_checkpoint": "..."}
▼
┌─────────────────────────────────────────┐
│ Work Record (event log) │
│ - Delivery timestamp │
│ - Acceptance status (pending) │
│ - Payment status (unpaid) │
└──────┬──────────────────────────────────┘
│ 8. Agent A reviews result
│ 9. POST /jobs/:id/accept or /jobs/:id/reject
▼
┌─────────────────────────────────────────┐
│ Settlement Layer (multisig or escrow) │
│ - Release payment on acceptance │
│ - Refund or dispute on rejection │
└─────────────────────────────────────────┘Key components:
- API + State Store: Centralized for the demo, but could be replaced with a distributed ledger or CRDT-based state.
- Discovery Layer: Matches jobs to agents based on keywords, capabilities, or embeddings.
- Term Negotiation: Versioned contracts that require re-approval if terms change.
- Work Record: Event log tracking delivery, acceptance, and payment separately.
- Settlement Layer: Handles payment release, refunds, and disputes.
Code: A Minimal Job Claim Flow
Here’s how an agent might claim a job and submit a state checkpoint:
import requests
import hashlib
import json
from datetime import datetime
class AgentClient:
def __init__(self, agent_id, private_key, terminal_url):
self.agent_id = agent_id
self.private_key = private_key
self.terminal_url = terminal_url
def sign_claim(self, job_id, terms_version):
"""Sign a job claim to prove agent identity.
Note: This uses naive SHA256 for demonstration. Production
systems should use proper asymmetric cryptography (Ed25519,
ECDSA) with signature verification.
"""
payload = f"{self.agent_id}:{job_id}:{terms_version}"
signature = hashlib.sha256(
(payload + self.private_key).encode()
).hexdigest()
return signature
def claim_job(self, job_id):
"""Claim a job and lock it for this agent."""
job = requests.get(f"{self.terminal_url}/jobs/{job_id}").json()
terms_version = job["terms"]["version"]
claim = {
"agent_id": self.agent_id,
"terms_version": terms_version,
"signature": self.sign_claim(job_id, terms_version),
"claimed_at": datetime.utcnow().isoformat()
}
response = requests.post(
f"{self.terminal_url}/jobs/{job_id}/claim",
json=claim
)
return response.json()
def deliver_result(self, job_id, result, state_checkpoint):
"""Submit work result with a state checkpoint for handoff."""
delivery = {
"agent_id": self.agent_id,
"result": result,
"state_checkpoint": state_checkpoint,
"delivered_at": datetime.utcnow().isoformat()
}
response = requests.post(
f"{self.terminal_url}/jobs/{job_id}/deliver",
json=delivery
)
return response.json()
# Example usage
agent = AgentClient(
agent_id="agent_b_research",
private_key="secret_key_123",
terminal_url="https://terminal.covenant.example"
)
# Claim a job
claim_result = agent.claim_job(job_id="job_001")
print(f"Claimed: {claim_result}")
# Execute task (simplified)
research_result = {
"summary": "Market analysis shows...",
"sources": ["url1", "url2"]
}
# Submit with checkpoint for potential handoff
checkpoint = {
"step": "research_complete",
"next_steps": ["format_report", "send_email"],
"context": {"topic": "AI agents", "depth": "technical"}
}
delivery = agent.deliver_result(
job_id="job_001",
result=research_result,
state_checkpoint=json.dumps(checkpoint)
)
print(f"Delivered: {delivery}")The state_checkpoint is the critical piece. If Agent B fails before formatting the report, Agent C can pick up from the research_complete step without redoing the research.
Trade-offs and Risks
| Dimension | Centralized Approach | Decentralized Approach |
|---|---|---|
| Discovery | Fast keyword search, single database | DHT or gossip, eventual consistency |
| Settlement | Escrow or payment processor | Multisig or smart contract |
| State handoff | Shared database, easy to query | Event log or CRDT, harder to sync |
| Trust model | Platform vouches for agents | Cryptographic attestation required |
| Failure mode | Platform downtime kills all jobs | Individual agent failures, no SPOF |
| Latency | Low (single DB query) | Higher (network consensus) |
| Cost | Platform fees | Gas fees or staking costs |
The current Covenant Terminal implementation leans centralized (keyword search, manual verification, 14-day trial). This is pragmatic for a demo but exposes the platform as a single point of failure and a trust bottleneck.
A fully decentralized version would need:
- A DHT or gossip protocol for discovery.
- Cryptographic capability attestation.
- On-chain or multisig settlement.
- Event-sourced state for handoff.
Each of these adds complexity and latency. The right choice depends on whether you prioritize speed (centralized) or resilience (decentralized).
Observability: What You Need to See
When agents hire other agents, you need visibility into:
- Job lifecycle: posted → claimed → in-progress → delivered → accepted → paid.
- Agent reputation: success rate, average completion time, dispute frequency.
- State checkpoints: where did the previous agent leave off?
- Payment flow: who owes what, and when does settlement happen?
- Failure modes: timeouts, rejections, partial completions.
A minimal observability stack:
- Structured logs: JSON events for each state transition (claim, deliver, accept, pay).
- Metrics: job completion rate, time-to-claim, time-to-deliver, dispute rate.
- Traces: distributed trace IDs linking the job poster, the claiming agent, and any handoff agents.
- Alerts: fire when a job is unclaimed for >1 hour, or when delivery is late.
Without this, you’re flying blind. You won’t know if agents are gaming the system, if jobs are stuck, or if the discovery layer is broken.
When to Use This Pattern
Agent-to-agent task delegation makes sense when:
- You have a heterogeneous agent ecosystem where no single orchestrator knows all capabilities.
- Tasks are long-running and may need handoff if an agent fails.
- You want agents to specialize (research, data transformation, API calls) and compose dynamically.
- You need a marketplace where agents compete on price, speed, or quality.
Avoid this pattern when:
- You control all agents and can use a central orchestrator (simpler, faster