Agent artifacts: what they are and why they vanish

Definition

The word artifact names the result rather than the process. A transcript records what the agent said. A patch records a change to source. An artifact is the thing a person can inspect or use: a rendered explanation, a working tool, a dashboard backed by data or a job that runs on a schedule. An artifact may consist of several layers. Its files describe the interface and behavior. A runtime serves or executes them. Data gives the result memory. Access rules decide who can open it. A URL gives people a route back. Losing any required layer can make the artifact effectively disappear even when a copy of the source still exists.

Subtypes

What to check before choosing

• Name the consumer. A developer may be satisfied with a branch and setup instructions. A customer or operator usually needs a URL, a clear access rule and an interface that works without local tools.
• List the required layers. Check files, runtime, database, login, schedule, domain and comments. A static report needs fewer layers than an internal application that records approvals.
• Define the lifetime. Session-long, review-long and indefinite are different requirements. A temporary preview can be correct for a quick check and wrong for a quarterly report people revisit.
• Preserve revision meaning. Record which source or input produced the artifact. A URL that changes invisibly can confuse a reviewer who returns after the underlying code changes.
• Test recovery. Pull or export the files, open the artifact outside the creator's account and confirm what happens when compute sleeps. Recovery evidence is more reliable than a vague promise of permanence.

Examples

Worked example: an agent investigates a slow API and produces a report with a latency chart, a table of endpoints and a small control that filters results by service. The HTML exists in a temporary directory, and the data is held by the process serving localhost. Sending a screenshot preserves the chart's appearance but loses the filter, citations and updated values. Sending the directory preserves files but asks every reviewer to install dependencies and find the right command. A durable artifact workflow instead identifies the report as a page artifact, publishes its files to a stable URL and includes the source links in the rendered result. If the filter needs only embedded data, it stays static. If reviewers add notes or the chart reads stored measurements, the artifact needs a workspace with data and access. The owner then opens the URL in a private browser, verifies the filter, checks the sharing mode and pulls the files once to prove recovery. Those checks test the artifact as reviewers experience it, not merely the agent's claim that generation succeeded.

Where Grain sits

Grain treats the artifact as the durable unit around a coding-agent workflow. The agent writes files, and the CLI publishes them to a workspace with a URL. Static pages can remain simple. Full apps can use Postgres, logins and scheduled jobs. Readers can receive a public link, a password-protected link or invite-only access, then leave comments that the agent can read and address. Published artifacts stay published on the free tier, and their files can be pulled with the CLI. Grain is not an agent and does not generate the artifact. It is not an IDE for human editing, and it is not a general production deployment platform. Use your existing coding agent to make the result. Use a production platform when repository-driven CI, release controls and production service operations are the actual job. Use Grain when the missing step is keeping the agent's useful output available to people.

Frequently asked questions