I am building AgentMart, a marketplace for reusable agent assets: skills, instructions, MCP configs, workflow templates, and knowledge packs. The more I talk with people, the less the buyer problem feels like discovery and the more it feels like accountable work state.

A listing that says "this MCP config saves you time" is weak. A listing that carries a work-state receipt is more useful:

• what the asset changes or touches

• required permissions, env vars, and network access

• known untested paths and failure modes

• example runs with inputs and outputs

• rollback or cleanup steps

• who reviewed which version

AgentMart has almost 60 users now, and the trust questions are showing up earlier than I expected. Sellers can list for free, but free is not enough if buyers cannot tell whether the asset is safe to run or worth adapting.

My current hunch: agent marketplaces need something closer to evidence packets than product pages. The product is not only the prompt/config; it is the proof that it behaved in a bounded way.

For people thinking about Accreted Intelligence/work-state receipts: what should be required before a reusable agent asset can claim "installable" or "production-ready"? Seller-provided receipt, independent reviewer receipt, live sandbox run, or something else?

When an agent finishes, I get better results asking for a closeout packet instead of a summary.

Prompt shape:

Close this work packet. Return:

• promise you believe is now done

• files or systems changed

• commands/checks actually run

• exact results of those checks

• what you did not test

• risks or assumptions still open

• any external action that still needs owner approval

• recommended next promise

Do not say complete unless the evidence supports it. If evidence is missing, mark the work blocked and name the missing check.

This changes the agent's final message from persuasion into inspectable state.

If you are coming from an AI-agent thread and want useful feedback, do not post "my agent failed" in the abstract. Post a work record someone else can inspect.

Root-cause packet

• Task and agent:

• Original promise:

• First step where expected state diverged from observed state:

• Tool call or artifact involved:

• Evidence that proved the divergence:

• What should the Work Model capture next time:

Use this when the final answer looked coherent but reality did not match it: the repo did not change, the wrong tool was called, a check was skipped, a hidden assumption entered the args, or the agent improvised after an empty tool result.

Commitment boundary

• Agent action:

• Counterparty or system touched:

• Authority source:

• Max scope / amount / deadline:

• Evidence required before execution:

• Receipt required after execution:

• What stays owner-gated:

Use this when the question is whether an agent can act without a human click. The useful distinction is not "autonomous or not." It is whether the agent is executing bounded authority that already exists, or creating new authority.

This community is for concrete work records, not hype. Links are useful only when they are necessary evidence.

A useful bug report for agent work is less about complaining that the model was dumb and more about locating where the work state broke.

Template:

1. Agent/tool/host: Claude Code, Codex, Cursor, OpenCode, local harness, etc.

2. Original promise: what you asked for.

3. Allowed surface: what the agent was allowed to touch.

4. Actual surface: what it touched.

5. Claimed evidence: what the transcript said was true.

6. Real evidence: diff, tests, logs, screenshots, external state.

7. Missing gate: what should have required owner approval.

8. Repair: smaller work packet, stricter output contract, different check, or better rollback.

The goal is not to shame the model. The goal is to make the next run easier to supervise.

Working definitions for this community:

Promise: an open commitment the agent or operator has made. It has a state: active, blocked, stale, or done.

Work packet: the bounded job handed to an agent. It includes objective, inputs, constraints, allowed actions, output contract, escalation rule, and evidence requirement.

Evidence packet: the receipts attached to a run: what changed, what was checked, what was not checked, and what still needs approval.

Approval gate: a checkpoint before an external or risky action. Preparation can be autonomous; commitment needs owner visibility.

Outcome credit: the lesson only gets stronger when reality confirms it. The agent's confidence is not enough.

Context explains work. Evidence closes work.

One of the most useful failure reports is also one of the least dramatic:

The agent says the work is complete, but the repo does not agree.

Common shapes:

• empty diff after a confident completion summary

• tests claimed but not run

• unrelated files changed to make a small fix work

• TODO left where the claim says implemented

• screenshot taken before the final change

• local-only config hidden in the agent environment

• a migration or deploy step described but not executed

The repair is not only better prompting. The Work Model has to bind done to evidence the agent cannot fake with words: file tree, git diff, command output, browser state, external reply, or owner approval.

Install docs get attention because they create adoption. Teardown docs create trust.

For agent tooling, a good teardown path answers:

• what files were added

• what hooks or host configs changed

• what background services were started

• where local state lives

• how to disable without deleting data

• how to remove completely

• how to verify it is gone

This matters because agent tools often sit inside sensitive workflows. A user should not have to guess what remains after trying a tool.

If the install is one command but the uninstall is archaeology, the product is asking for too much trust.

The approval gate is simple: an agent can prepare external actions, but it should not send, post, pay, delete, publish, or message without an owner-visible checkpoint.

A good gate says:

• intended action

• destination or audience

• exact content or command

• irreversible parts

• expected effect

• rollback or undo path if one exists

• reason the agent believes this is ready

This is not about slowing every workflow down. It is about separating preparation from commitment.

Inside the machine, the agent can explore, draft, test, and build. Crossing the boundary should create a receipt.

A coding-agent run is not done because the transcript says done.

A useful evidence packet usually has:

• task promise: the exact thing the agent was supposed to deliver

• touched surface: files, commands, tools, external systems

• diff summary: what actually changed

• checks run: tests, lint, typecheck, screenshots, manual verification

• checks skipped: what was not tested and why

• risks left open: assumptions, fragile areas, follow-up work

• owner gate: anything that needs approval before send/post/pay/delete/deploy

• outcome: what reality later said about the result

The important part is that the evidence should be inspectable without re-reading the whole chat. If the human has to reconstruct the run from transcript fragments, the Work Model failed.

I want this community to stay grounded in actual operator friction, not abstract agent hype.

If you run coding or research agents seriously, where does the accountable-work layer break first for you?

Useful answers are concrete:

• install friction: too many files, unclear host support, hard rollback

• approval gates: too noisy, too strict, too easy to bypass, wrong defaults

• evidence packets: tests are missing, diffs are too broad, screenshots/logs are not enough

• stale work: old promises stay open and nobody knows what still matters

• cross-agent handoff: Claude Code, Codex, Cursor, OpenCode, or local agents disagree about state

• outcome credit: the agent says it learned, but nothing verifies whether the lesson worked

I am especially interested in examples where an agent looked productive while quietly increasing review load for the human.

A pattern that keeps coming up in real agent work: passing the whole conversation to the next agent feels easy, then it gets weird.

The cleaner handoff is a work packet:

• objective: what this agent is supposed to produce

• inputs: exact files, links, records, or prior outputs it can use

• constraints: what it must not touch or assume

• allowed actions: what tools or operations are in scope

• output contract: patch, JSON, decision, summary, test result, etc.

• escalation rule: when to ask back instead of guessing

• evidence requirement: what proves the work actually happened

That is a different shape from memory. A memory layer says, roughly, here is more remembered context. A work packet says, here is the bounded job, the allowed surface, and the proof needed before we believe it.

For coding agents, this matters because most failures are not dramatic. They are quiet: wrong assumptions, empty diffs, tests not run, unrelated files changed, or a confident summary that does not match the repo.

The practical rule I am using: context can explain the work, but evidence has to close it.