Your AI Agent Ran for Three Days. The Career Proof Is the Ledger You Kept.

An AI agent running for three days sounds impressive until an interviewer asks what happened during those three days. How was the objective bounded? Which branches failed? What evidence changed the plan? Who approved the risky action? Why should anyone trust the final result? If the only answers are a runtime counter and a polished output, the work is still difficult to assess. As agents become able to operate longer and coordinate more workers, the strongest career evidence is shifting from the output to the ledger that makes the work reconstructable.

That shift became concrete this month. OpenAI's new Agents API is designed for agents that can work across days, coordinate subagents, use files and tools, and save intermediate results.^[1] Anthropic, writing about oversight at frontier scale, emphasized persistent agent identity, attributable actions, monitor coverage, review latency, and escalation.^[2] These are infrastructure and safety developments, not hiring standards. But they reveal the same underlying problem employers face when a candidate says, "I built an agent that handled the whole project."

Capability without a record creates an attribution gap. The reviewer sees what appeared at the end, but not the decisions that made it dependable. Your job is to close that gap without dumping a private transcript or pretending every logged action deserves attention.

Agent-hours are an activity metric, not a competence claim

Runtime, token usage, number of subagents, and tool calls can describe the scale of a run. They do not establish that the work was useful. A workflow can consume enormous resources while pursuing a weak objective, duplicating effort, retrying the same failure, or producing an answer nobody accepts.

This is already visible in frontier workflows. OpenAI reports that researchers increasingly use concurrent coding agents and delegate higher-level, longer-horizon tasks, while high-level planning remains a small fraction of coding-agent output tokens.^[3] Treat those figures as one company's internal account, not a universal productivity benchmark. The practical signal is the separation between abundant execution and scarce direction.

That separation changes what a hiring manager needs to learn about you:

• Did you choose a consequential problem and define "done" before the run?
• Did you divide the work so parallel activity reduced uncertainty rather than multiplying noise?
• Could you tell the difference between progress, motion, and a confident dead end?
• Did you preserve evidence when the plan changed?
• Did you know which actions required human approval?
• Could another reviewer reconstruct why the accepted result won?

A transcript rarely answers those questions efficiently. Raw logs mix meaningful decisions with setup chatter, retries, generated reasoning, secrets, and details that should never leave a workplace. A carefully edited case study can also go too far in the other direction, sanding away failures until the project looks inevitable.

The useful middle layer is an agent work ledger: a compact, chronological record of consequential state changes and the evidence behind them. It is closer to a decision log plus an experiment record than a diary of everything the agent said.

Build the ledger around seven fields

Use the LEDGERS framework: Limit, Expected result, Decisions, Gates, Exceptions, Review, and Scorecard. The acronym matters less than the discipline. Each field makes a different part of your ownership visible.

Limit: define the authority boundary

State what the workflow may read, change, publish, spend, or trigger. Name what remains outside its authority.

For a dependency migration, the agent might read the repository, documentation, issue tracker, and test output. It may create a branch and propose patches. It may not merge, rotate credentials, change production infrastructure, or dismiss a failing security test.

This boundary does two jobs. It reduces operational risk, and it prevents your career story from quietly overstating autonomy. "Produced a reviewable migration branch under repository and CI constraints" is often more credible than "autonomously migrated the platform."

Expected result: write the acceptance contract first

Describe the required artifact and the conditions for accepting it. Avoid goals such as "modernize the service" or "improve the code." They give the agent room to generate activity without creating a falsifiable result.

A useful contract might require all supported builds to pass, deprecated calls to disappear from the target package, benchmark performance to remain within an agreed range, and a human maintainer to approve the compatibility note. Add explicit non-goals, such as redesigning unrelated modules.

This field is the anchor for the rest of the ledger. Anthropic's guidance on agent evals makes the same practical point: an eval pairs representative tasks with grading logic that defines success.^[4] If you decide how to grade only after seeing the output, a persuasive demo can move the goalposts.

Decisions: record forks that changed the plan

Do not record every command. Capture choices where another reasonable route existed: which migration strategy to use, which evidence overruled the initial plan, why a branch was abandoned, or why a check became mandatory.

Each decision entry needs four short elements:

1. The question being decided
2. The options considered
3. The evidence used
4. The chosen path and owner

The owner matters. An agent can propose a route; a human can accept it; a policy can force it. Those are different claims. Persistent identities and attributable records help large agent systems distinguish one worker's output from another worker's claims.^[2] Your small project needs the same conceptual clarity even if the implementation is a Markdown table.

Gates: preserve checkpoint evidence

A gate is a condition that must pass before the workflow expands its authority or moves into a costlier phase. Examples include schema validation before data import, unit tests before broad refactoring, a privacy review before using real records, or maintainer approval before opening a pull request.

Write down the artifact examined, the result, and the consequence. "Tests passed" is too thin. Prefer "412 unit tests passed; two contract tests failed on timestamp normalization; rollout stopped and the parsing branch was revised."

Gates make restraint visible. They show that you designed the project so evidence could interrupt momentum.

Exceptions: keep the failure that improved the system

A polished portfolio tends to hide the most valuable evidence: the moment the workflow behaved badly enough to expose a missing assumption. Keep representative exceptions, especially when they changed a guardrail, test, or operating rule.

An exception entry should explain what happened, its impact, how it was detected, what contained it, and what changed afterward. Do not turn a minor formatting issue into a heroic incident. Choose failures that reveal judgment.

For example, a migration agent may update a public API correctly but overlook a reflection-based internal caller. The build passes while an integration fixture fails. The candidate adds repository-wide symbol tracing and a fixture that covers dynamic loading. That sequence proves more than an error-free demo because it exposes the feedback loop.

Review: show who challenged the result

Name the reviewer, their relevant role, what they examined, and what changed after review. "Human in the loop" is not specific enough. A security engineer reviewing permission boundaries is different from a teammate reading the summary. Both can be useful, but they support different claims.

Independent review is becoming more prominent in frontier AI governance as well. Anthropic's newly announced embedded-evaluation partnership is explicitly designed to give outside evaluators deeper access, while the company also notes that the operating model remains new.^[5] A portfolio project does not need an institutional evaluator. It does need a second set of eyes with enough context to disagree meaningfully.

Scorecard: compare the result with a baseline

Close the ledger with a small scorecard tied to the acceptance contract. Use measures that fit the task: defects found, cases passed, reviewer corrections, setup time, processing time, cost, source coverage, or unresolved risks.

Avoid selecting only flattering metrics. If the workflow cut active effort but increased compute cost, show both. If it handled routine cases well and escalated three edge cases, say so. A bounded result gives a hiring manager something they can believe.

If you already have one truthful version of this story, CoreCV's role-targeted resume workflow can help you emphasize the ledger evidence most relevant to a pasted job description or job URL while keeping the underlying facts consistent.

A worked example: a five-day dependency migration

Imagine a platform engineer wants to demonstrate long-running agent work. The project is migrating an internal TypeScript service from an aging authentication library to a supported version. The repository has good unit coverage, incomplete integration fixtures, and one undocumented plugin surface.

The weak case study says:

Used four AI agents over five days to migrate 38 files, write tests, and update documentation, saving an estimated three weeks of engineering time.

The scale sounds substantial, but nearly every important claim is unsupported. Four agents may have duplicated one another. Thirty-eight files may be busywork. The time estimate may be imaginary. Passing generated tests may say little if the tests repeat the implementation's misunderstanding.

The ledger creates a stronger story.

Limit: Agents could inspect the repository, vendor migration guide, and CI output; create branch-scoped changes; and propose test cases. They could not merge, modify production secrets, or change authorization policy.

Expected result: Supported builds pass, deprecated authentication calls are removed from the target service, five named flows preserve behavior, and the platform owner approves the rollout note. Plugin redesign is excluded.

Decision 01: Choose an adapter migration over direct replacement. Repository search found eleven call shapes and a plugin interface maintained outside the target team. The candidate accepted the adapter plan to contain compatibility risk.

Gate 01: Baseline recorded before edits: 412 unit tests and 23 integration cases passed. One known flaky case was isolated and linked to an existing issue.

Exception 01: A subagent reported the migration complete after unit tests passed. An integration fixture failed because a dynamically loaded plugin expected the old error type. Work stopped before the pull request. The candidate added a compatibility mapping and a regression fixture.

Decision 02: Keep the compatibility mapping local instead of changing the shared plugin contract. The plugin owner confirmed that a broader contract change would affect two unscoped services.

Gate 02: All baseline tests and the new regression case passed. Static search found no deprecated calls in the target package. A security reviewer examined token handling and found no new secret path.

Review: The platform owner requested a rollback trigger for elevated authentication failures. The candidate added a threshold and linked monitoring query to the rollout note.

Scorecard: The accepted pull request changed 24 production files and added six fixtures. Two agent-proposed branches were rejected. Reviewer corrections changed one compatibility behavior and one rollout control. Active engineering time was recorded, not converted into a speculative weeks-saved number.

This version gives an interviewer several places to probe. That is a strength. The candidate can explain the adapter tradeoff, the dynamic-loading blind spot, the test boundary, the rejected branches, and the review change. The project is no longer a story about leaving agents unattended. It is a story about building an evidence system that made extended delegation governable.

Do not publish a raw transcript

Reconstructability does not require total disclosure. Raw agent transcripts can contain customer data, credentials, unpublished code, private deliberation, licensed material, prompt-injection content, or generated reasoning that is both noisy and misleading. They can also reveal more about an employer than you have permission to share.

Use three disclosure layers.

Publish the case record

Share the sanitized objective, authority boundary, acceptance criteria, consequential decisions, representative exception, review path, and scorecard. Link public commits, tests, issues, or demo artifacts when you own them.

Summarize protected evidence

For confidential work, preserve the shape of the evidence without exposing the content. You can say that a reviewer checked six representative cases, that one policy conflict forced escalation, or that an internal test suite passed. Label reconstructed examples clearly.

Keep restricted records private

Secrets, customer inputs, internal transcripts, security findings, and proprietary implementation detail should remain in the approved system. A portfolio is not an excuse to move workplace data into a personal repository.

This is also why a ledger should store references and outcomes rather than every hidden reasoning trace. The reviewer needs to see the claim, evidence, decision, and owner. They do not need a theatrical stream of machine thought.

Turn one ledger into three career artifacts

The same evidence should appear at different resolutions in your portfolio, resume, and interview. Consistency matters more than repetition.

Portfolio: make the evidence path skimmable

Lead with the problem, boundary, and accepted outcome. Then show a compact timeline with the decisions, gates, and exception that changed the work. End with the scorecard, limitations, and what you would test next.

Link to deeper artifacts selectively. A reviewer should be able to understand the project in five minutes without opening a transcript. This extends the principle behind packaging an AI workflow someone else can run: portability proves the procedure can travel; the ledger proves a consequential run can be assessed afterward.

Resume: compress judgment and result into one claim

Do not lead with the number of agents. Lead with the owned outcome and include the control that made the result credible.

Weak:

Orchestrated four AI agents for 120 hours to complete an authentication migration.

Stronger:

Led a bounded authentication-library migration across 24 production files, using branch-scoped agents, baseline and regression gates, and platform-owner review to preserve five critical flows and add six missing integration fixtures.

The stronger bullet is longer, but each phrase earns space. It identifies scope, method, verification, review, and accepted evidence. If a target role values security, emphasize the authority boundary and token-path review. If it values developer productivity, emphasize the adapter decision and regression coverage. Keep both versions anchored to the same ledger so tailoring does not invent a new project.

Use the defend-every-line audit before submitting. You should be able to explain every scope number, test count, decision, and ownership verb under follow-up.

Interview: narrate the decision loop

Start with the acceptance contract, then choose one fork and one exception. Explain what evidence arrived, why it changed the plan, what remained yours to decide, and how review affected the outcome.

A useful answer follows this sequence:

1. "We defined success as..."
2. "The agents were allowed to... and could not..."
3. "At the first gate, we learned..."
4. "I rejected the initial route because..."
5. "The failure exposed... so I changed..."
6. "The reviewer challenged..."
7. "We accepted the result when..."

That sequence prevents the common interview failure where a candidate can describe the tool but not the work. It also makes honest boundaries easier to state. You do not need to claim that you wrote every line when your stronger contribution was defining the system that decided which lines survived.

Multiagent work needs a ledger even more

Adding agents increases coordination surface. Workers can duplicate research, inherit a bad premise, overwrite one another's changes, or repeat a claim until it feels independently confirmed. Anthropic's multiagent research emphasizes that interactions among agents in shared systems remain an emerging and uncertain field.^[6]

For a multiagent project, add three details to the ledger:

• Assignment map: which worker owned which question, artifact, or decision boundary
• Source provenance: whether a claim came from an original source, another agent, a test, or a human reviewer
• Conflict record: where workers disagreed, how the conflict was resolved, and who accepted the resolution

Do not count repeated agent agreement as independent verification when the agents share the same source or initial assumption. Independence comes from different evidence, tests, methods, or reviewers, not different labels in a dashboard.

The same caution applies to handoffs. A workflow that survives another person's use is stronger than a solo demo. A ledger adds the missing temporal layer: it lets the next person see which state is current, which branch died, which risks remain, and why the previous operator stopped where they did.

Build your first ledger this week

Do not wait for a three-day agent run. Choose one repeated task that takes a few hours and has a reviewable result. A data cleanup, dependency update, research synthesis, support triage, test expansion, or documentation migration is enough.

Before running anything, write the Limit and Expected result fields. Capture a baseline. During the work, log only consequential Decisions, Gates, and Exceptions. Ask one qualified person to perform the Review. Close with a Scorecard that includes at least one limitation or unresolved risk.

Then perform an evidence audit:

• Can every number be traced to a test, diff, issue, measurement, or approved record?
• Can the reviewer tell which decisions were yours, the agent's proposals, or policy requirements?
• Does the case preserve one meaningful failure without exposing restricted material?
• Do the resume bullet and portfolio case make the same underlying claim?
• Could you explain why the accepted result beat the rejected alternatives?

Long-running agents will make it easier to generate impressive quantities of work. That abundance raises the value of a rarer skill: making delegated work accountable. The candidate who can show an objective, an authority boundary, an evidence trail, a correction, and an accepted result gives an employer something much more useful than proof that an agent stayed busy.

For one practical research breakdown each week, follow the AI Career Signals archive. The series translates changes in AI work into decisions you can use across your resume, portfolio, interviews, and job search.

Disclosure: This article is authored by the CoreCV team. While we mention CoreCV.ai, the strategies and advice presented here are intended to be useful whether or not you use our product.

Sources

1. OpenAI, "Introducing the Agents API", September 10, 2026.
2. Anthropic, "Measurements for understanding the pace of AI development inside frontier labs", September 17, 2026.
3. OpenAI, "Research acceleration: The view inside OpenAI", September 6, 2026.
4. Anthropic, "Demystifying evals for AI agents", January 9, 2026.
5. Anthropic, "Partnering with Accenture on embedded evaluation", September 18, 2026.
6. Anthropic, "Patterns and problems in emerging multiagent systems", August 13, 2026.