[Use Case] One prompt, 168 hours: reconstructing what an unattended agent did under a single delegation

1. Identification

Title: One prompt, 168 hours: reconstructing what an unattended agent did under a single delegation
Submitting organization: Agent Community (Open Agent Registry, Inc.)
Contact name: Balazs Nemethi
Contact email: bn@agentcommunity.org

Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [ ] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Software development and developer services; cross-sector (any long-running autonomous agent acting through a person's accounts)

2. The situation

Plain language description (required, 3 sentences max):
An operator gives a coding agent one written goal, plus accounts, keys and spending limits prepared in advance, and then may not intervene for 168 hours except to type "keep going" after a crash or stop. During that week the agent and the subagents it spawns create repositories, call APIs, deploy services and may sign up for or pay for things, all through authority the operator set up once at the start. Afterwards, people who were not there (organizers, judges, and the services the agent touched) have to work out what the agent did, which instance did it, under what authority, and whether a human stepped in.

Actor (every party involved):
The operator (principal and deployer); the root agent and its subagents, all inside one agent harness; the harness vendor and the model provider; third-party services the agent uses through the operator's prepared accounts (code hosting, cloud, package registries, payment providers, email); Agent Community as organizer, running an open-source tracer and verifier; judges and reviewers who see only the sealed result.

Action:
Over 168 hours the agent reads and writes files, runs shell commands, creates and pushes to repositories, deploys infrastructure, calls external APIs, and may create accounts or make purchases within the limits the operator prepared. Some of these actions are reversible (commits, deployments). Some are not (payments, public releases, messages sent to other people).

Decision required (at the moment the agent acts, what does the party on the receiving end have to decide?):
At action time, for a service receiving a request on day five: "Is this request coming from an agent acting on the operator's one-time mandate from day one, and is it within that mandate?" After the run, for a reviewer: "Was each external action taken by the agent (root or subagent) rather than a human, and did any human input other than 'keep going' reach the agent after the start?"

Problem encountered (why that decision cannot be made today):
External services see only the operator's credentials, so they cannot tell the operator from the agent, or a subagent from the root agent. The mandate exists only as a natural-language prompt, with no machine-readable scope a service could check. The only record of what happened is the harness's local session files: their formats differ between vendors, they change between versions, and whoever controls the machine can edit them.

Current mitigation:
For /goal Cup we built an open-source tracer (agentcommunity/goal-cup-tracer). It launches the agent, records its model traffic and the harness's own session files (the exact prompt, every later human message, tool calls and results, subagent lineage, harness and model identity), and hash-chains them into one trace. During the run it uploads the chain in chunks, and the server signs an acknowledgement of each chunk, so a later rewrite on the operator's machine no longer matches the server's copy. At 168 hours the workspace is sealed, and an open-source verifier checks the whole trace offline. Operators are encouraged, not required, to give the agent dedicated identities (a GitHub App, a bot user) so that services can tell its writes apart.

Residual gap:
Everything the tracer establishes is visible only to the organizer, not to the services the agent acts on. There is no standard way to (a) express the operator's mandate in a form a service can check, (b) bind an action at a third-party service to a specific agent instance and its delegation chain, (c) keep agent identity continuous across crashes, resumes and context compaction over several days, or (d) let a third party verify the record without trusting the operator or the harness vendor.

3. Actors and context

Taxonomy roles involved
- [x] Principal — the operator, who writes the goal and prepares the authority the agent may use
- [x] Relying party — third-party services at action time; organizers and judges after the run
- [x] Builder — harness vendors and model providers
- [x] Deployer / Owner — the operator
- [x] Agent instance — the root agent and each subagent; one session that may crash and resume several times
- [ ] User
- [x] Infra provider — model API providers, cloud and hosting providers used by the agent
- [x] Attestor — the organizer's tracer server, which timestamps the start and acknowledges trace records
- [x] Other (specify): Judges who see only the sealed product, the prompt and the disclosed setup, never the raw trace

Mandates in this case (required)

Cross-border?
- [x] Yes — jurisdictions involved: operators participate globally; the organizer is US-based; model, cloud and payment providers operate in several jurisdictions
- [ ] No

Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No

Agent action type (required; tick all that apply. Where several apply, the most consequential governs the case)
- [x] Read-only
- [x] Consequential (reversible)
- [x] Irreversible — purchases, public releases and messages sent to third parties govern the case

Crosses organisational boundary? (required)
- [x] Yes (specify): the agent acts at independent third-party services through the operator's accounts, and the organizer verifies the run without controlling the operator's machine
- [ ] No

Risk level (required)
- [ ] Low
- [x] Medium — bounded by spending limits and a fixed time window, but with irreversible actions taken by an agent that no human supervises for a week
- [ ] High

4. Theme relevance

Related theme proposals:
- Theme #1 — Accountability and attribution after an agent has acted: this case is a live test of it, at the scale of thousands of actions per run.
- Theme #9 — Authority that was never crisply authored: the entire mandate is a prompt of up to 4,000 characters.
- Theme #31 — Preserving authority boundaries across agent memory and context handoffs: a week-long run compacts and hands off context many times.
- Theme #16 — Operational human oversight integration: the opposite end, where oversight is deliberately removed and we observe what happens.

5. Requirements

6. Assessment criteria

Success criteria:
For each sealed run, a reviewer who did not take part, working only from the record and without the operator's help, can: list every external action; attribute each one to the root agent or a named subagent; confirm whether any human message other than "keep going" reached the agent; and say whether each irreversible action falls within the stated mandate.

Measurable metric:
Reported after the runs: share of external actions attributable to an agent instance and mandate; share of runs verified automatically without manual review; number and length of capture gaps, split into clean and unobserved-activity gaps; reviewer time needed to reconstruct one run. We can share the aggregate figures with the Focus Group before the Paris meeting.

7. Duplication check

Existing standards or SDOs (which existing work touches this case):
OpenTelemetry semantic conventions for generative AI (tracing of model and tool calls); IETF OAuth work on delegated access for agents acting on behalf of users; IETF WIMSE (workload identity); IETF SCITT (append-only transparency for signed statements); W3C Verifiable Credentials; agent trajectory formats such as ATIF; IETF DAWN discussions on agent discovery.

Overlap notes (why the work named above does not already solve this):
Each covers one piece. Tracing formats describe what happened but not who authorized it, and do not resist edits by the machine owner. Delegation and workload-identity work covers short-lived, request-scoped authority, not a single natural-language mandate that subagents carry forward for a week. Transparency logs can anchor a record but do not define what an agent record must contain. Nothing links the mandate, the agent instance lineage, and a third-party-verifiable action record end to end.

8. Maturity

Pilot status

• [ ] Hypothetical
• [x] Pilot in progress — /goal Cup runs start 7 November 2026 (00:00 UTC, 24-hour start window); each run lasts 168 hours
• [ ] Deployed in production

Reference implementation: https://github.com/agentcommunity/goal-cup-tracer (open-source tracer and offline verifier). Event: https://agentcommunity.org/goalcup

9. IP and confidentiality

Confidentiality level

• [x] Public
• [ ] FG-internal only
• [ ] Redact before publication

IP notes (optional): The tracer and verifier are open source. Raw traces stay private; any trace data shared with research partners requires participant opt-in and redaction. Aggregate findings will be published.

10. Assets

Link to assets:
- [ ] Dataset — aggregate findings after the runs; raw traces only with participant opt-in and redaction
- [x] Code — https://github.com/agentcommunity/goal-cup-tracer
- [ ] Protocol
- [x] Other: competition rules (one prompt, "keep going" only, 168-hour seal) — https://agentcommunity.org/goalcup

IP notes (optional):