The more work an AI agent does for you, the worse a chat log is as the thing you review. Everything is in there — which is exactly why nothing is findable afterwards.
What I want at the end of a delegated job is not the transcript. It is one page: what was completed, what was verified, what is still unverified, what is waiting on my approval, and what to look at next. The conversation is where you go back to. The artifact is where you decide.
You do not need a product for this. In my Codex operation, a Markdown doc is enough.
Originally published in Japanese on June 20, 2026. This English version was written in September 2026.
Agent logs are good for process, too long for review
A work log shows what premises were handed over, what was investigated, where the agent hesitated, and which commands ran. That is a real strength of a conversational interface when you are reconstructing how something happened.
As a review object, it is far too long. Publishing a blog post, for instance, is not one step. It is publishing in WordPress, checking the rendered HTML, checking title, description, canonical, and OGP, checking image alt text, recording the publication in docs, running a URL inspection in Search Console, submitting to Hatena Bookmark (a Japanese social bookmarking service that still drives meaningful referral traffic here), handing the post to an X thread, recording the post-publication observation schedule, and noting internal link candidates.
Delegate that and the work gets done. But what a human needs to look at afterwards is not the whole conversation. It is the outcome: what completed, what is unverified, where an approval is pending, and what to check next. If that does not fit on one page, you cannot accept the delegated work with any confidence.
What Claude Code Artifacts pointed at
On June 18, 2026, Anthropic announced artifacts in Claude Code: turning a session’s work into live, shareable web pages — PR walkthroughs, system explainers, dashboards, release checklists — that update as the session works. Per the announcement, an artifact is built from the full session context, including the codebase, connectors, and the conversation, and every publish is a new version at the same link with version history.
Two things about scope, and both have since moved. The June announcement said artifacts were private to the author, viewable only by authenticated members of the org, could not be made public, and were in beta for Claude Team and Enterprise orgs. That blog post has not been updated, but the product has: as of September 2026 the Claude Code documentation lists artifacts on Pro, Max, Team and Enterprise plans, with public link sharing supported — on Pro and Max a public link is in fact the only way to share one. Read the announcement as a snapshot of June 2026, not as current scope.
So this is not a Codex feature, and not something a solo operator needs to adopt as an external service. What interested me was the direction, not the product: agent work being handed over as a reviewable deliverable rather than a transcript. That idea transfers to a Codex setup immediately.
A Markdown doc does the job
In my own operation the artifact is a Markdown file. The point is not visual richness. It is that once the work is finished, everything a human needs in order to make a decision sits on one page.
For post-publication work, that is a single note — a Blog Release Artifact — carrying the published URL, verified items, unverified items, pending approvals, outbound external actions, sources used, remaining tasks, and the procedure to use next.
Codex work runs long: verify the published page, update docs, notify another thread, then tidy up the remaining tasks. At the end of that, a report saying it went well is worthless. A deliverable you can check is not.
The fields that matter
The generic version is plain:
# Agent work artifact: <job name>
- Goal:
- Completed:
- Verified:
- Unverified:
- Awaiting approval:
- Sent externally:
- Sources used:
- Deliberately untouched:
- Next:For post-publication work it gets more concrete:
# Blog release artifact: <article title>
- URL:
- Publication verified:
- Rendered-page check:
- Docs synced:
- X notification:
- Search Console:
- Social bookmark submission:
- Post-publication observation schedule:
- Internal link candidates:
- Remaining tasks:
- Skill to use next:The goal is not to automate all of it. It is to keep three pairs separate: verified versus unverified, completed versus awaiting approval, and what the agent did versus what a human still has to look at. That alone removes most of the post-delegation unease.
It matters most where an operation reaches outside your own systems — posting to X, Search Console, social bookmark submission, editing existing articles. Before you argue about whether to automate those, make the state visible: was it sent, not sent, or attempted and failed, and does a human decide next? At that granularity you stop second-guessing later.
An artifact is a review surface, not a substitute for automation
“Make an artifact” suggests a polished dashboard. For my purposes it does not need to be one. What has to be decided first is how you receive agent work: read the whole log, read a summary, or read a deliverable with verified items and remaining tasks separated. The third fits actual operations best.
Once agents act as workers, the human stops being a reader of work logs and becomes a reviewer of deliverables. So the artifact needs decision-relevant fields, not presentation: the goal, what finished, what was verified, what was not, where approval is needed, which sources were used, what was left untouched, and what happens next. Starting small is what makes it stick.
Keeping secrets out is part of the format
An artifact is not a place to dump everything. Anything that may be shared or reused should exclude credentials, authentication-related values, account-specific identifiers, and internal-only URLs. The observation plan does not need internal structure spelled out either.
“Check in Search Console,” “record the post-publication observation schedule,” “review at 7, 14, and 28 days,” “revisit internal link candidates later,” “adjust title or description if needed” — that level of detail is sufficient. Which sheet, which row, which internal identifier, which internal URL: neither the reader nor the agent needs it.
An artifact holds what a human needs in order to judge, and nothing else.
Start with the post-publication check
Trying to convert every job into an artifact at once will not survive contact with a normal week. The post-publication check is the right first candidate: the steps repeat, the check items are well defined, external actions and pending approvals get mixed in, and it is genuinely worth re-reading later.
The same holds outside blogging — an app release, a PR review, a research pass, a safety review of a candidate MCP server, a comparison of design options. Each can end with one page answering “what do I need to see in order to decide?”
The more you delegate, the more the receiving format matters relative to the prompt. Not only what you ask for, but what shape the result arrives in.
Ask for a deliverable, not a log
Claude Code Artifacts pointed at turning agent work into shareable pages. In my own Codex operation, a Markdown doc gets there before adding any external service.
The conversation is the process. The artifact is the review object. Separating those two is most of the benefit.
So the closing instruction changes. Not “show me the work log,” but “give me this as something I can review.” That is the version where the human gets to concentrate on the decision.
Related
- What Codex’s banked rate limit reset actually does
- Checking the local environment, not just the usage meter