A folder is an agent

Ask where an agent lives in most organisations and the honest answer is: in a text box. A system prompt pasted into a vendor console, a list of tools ticked in a settings page, a few knobs for temperature and model, a workflow drawn in a visual builder. The agent is real enough to send emails and move money, but it has no source. You cannot diff yesterday's version against today's. You cannot see who changed the instruction that made it start refunding customers. You cannot run it on your own machine to check what it would do.

Software stopped working this way decades ago, for good reasons. Code that acts on your behalf lives in files, under version control, behind review. Agents act on your behalf more directly than most code does. They should be held to the same standard: an agent should be a folder you can read.

Dashboards hide the decisions that matter

The problem with an agent defined in a dashboard is not that dashboards are bad interfaces. It is that the definition is not an artefact. It cannot be reviewed before it changes, reproduced after an incident, or moved from one host to another. The important decisions, such as which tools the agent may call, which of them change state, when it must stop and ask a person, and what it is allowed to remember, sit in configuration that only the platform can read back.

That has three consequences. Review becomes impossible, because there is no change to review. Accountability becomes vague, because there is no history of who decided what. And portability disappears, because the agent is defined in one vendor's schema.

The ecosystem is already moving to files and open protocols

The broader industry has been converging on plain, open conventions. OpenAI released AGENTS.md, a file in a repository that tells coding agents how to work in it, in August 2025, and says it has been adopted by more than 60,000 open-source projects and agent frameworks; it is now a founding project of the Agentic AI Foundation under the Linux Foundation (OpenAI). The Model Context Protocol, for connecting agents to tools, was donated to the same foundation in December 2025 (Anthropic). The Agent2Agent protocol, for agents talking to agents, became a Linux Foundation project in June 2025 (Google). AG-UI is an open, event-driven protocol for connecting agents to front-end applications (AG-UI).

What is missing is the step that joins them: the agent itself as a file-based, reviewable unit that speaks all of these protocols, rather than a definition locked inside the platform that happens to speak them.

What a folder-shaped agent looks like

Praecise Harness, an open-source TypeScript framework under Apache-2.0, takes that position literally: a folder is an app (README). Its layout is the design argument.

• agents/ holds one file per agent. agents/support.ts defines an agent called support. Only its role is required; it can also declare what it knows, which tools it may use, its rules, a structured shape it returns, its memory, access and effect.
• memory/ holds Markdown and text files every agent can answer from.
• tools/ declares the services the app may act through, each by URL, by command or by OpenAPI document. An OpenAPI document becomes one tool per operation.
• functions/ holds the team's own code that an agent can call.
• workflows/ holds one file per workflow.
• stores/ declares where data is kept.
• guard.ts decides, in code, which tool calls the app actually makes. Refusals go back to the model as text, and effects are declared as read, write or destructive.

Everything that determines behaviour is in the folder. A pull request that gives an agent a new tool, loosens a rule or changes the guard is a diff a colleague can read and approve.

One definition, every interface

A file-based agent should not have to be rewritten for each way it is reached. From the same folder, the Harness serves each agent as a chat UI, a REST endpoint, an MCP server, an A2A agent with an agent card, and AG-UI streaming. The agent is defined once; the protocols are projections of it.

This matters for review as well as convenience. When the same definition answers a person in a chat window and another agent over A2A, there is one place to check what it may do, not five integrations that might have drifted apart.

Workflows that stop for a person, durably

Delegation needs points where a person decides. In the Harness, a workflow is built from seven step kinds: ask delegates to an agent, use calls a service, approve stops and waits for a human, each runs steps per item, when branches, repeat loops until a check holds with a required maximum, and plan lets a model lay out the remaining work. Steps run in order unless dependencies are declared, in which case they form a graph that can run in parallel.

The approval gate is durable. An approve step writes the run to disk and returns, so it survives restarts, and resuming replays recorded outputs rather than re-running earlier steps. A journal lets a run be resumed at a gate, recovered after its process died, or forked from an earlier point to test a patched step. A step interrupted in the middle of a side effect is marked in flight, and recovery refuses to repeat it automatically. The README is also candid about a limit: approvals are recorded unsigned unless the app wires its own signing and verification.

Stores and models, declared rather than configured

Data and model choice follow the same pattern. A store is declared in a file by family, with SQL, document, time-series and vector served by the shipped backends, and the built-in store is a local file that needs no installation. The same verbs work on every store: remember, recall, search, history and forget. Model selection is a single quality dial, fast, balanced or best. Routing is per request: easy requests go to an inexpensive model and large ones to a stronger one, and near the edge of a model's capability the same question is asked more than once and the answers compared. Everything else that a dashboard would expose as settings is derived from what the folder declares.

What this means for researchers

File-based agents make agent behaviour a reproducible object of study. A folder can be checked out at a commit, run against a fixed input and compared with a later version. Changes to tools, rules or guards become variables you can isolate rather than undocumented drift in a hosted configuration. Durable journals that can be forked from a point in a run make it possible to study counterfactuals: what would the agent have done if this step had returned something else?

What this means for CTOs

Apply the controls you already trust. Put agents in repositories, require review for changes to tools, guards and approval steps, and deploy them from a build like any other service. Prefer agents whose permissions are expressed in code you can read, with effects declared, over permissions held in a vendor's settings page. And insist that the same definition serves every interface, so there is one thing to audit.

Where Praecise fits

Praecise Harness is the open-source framework for AI agents, licensed Apache-2.0 and published on npm as @praecise/harness, running on Node 22 or newer. A folder is an app: it serves a chat UI, REST, MCP, A2A and AG-UI; takes tools from any MCP server or any OpenAPI document, with OAuth 2.1 using resource indicators and PKCE; runs workflows with seven step kinds, a durable approve gate and a journal that can resume, recover or fork a run; ingests documents into SQL, document, time-series and vector stores; and enforces its tool calls through guard.ts. Praecise Cloud is the managed side of the same app: one command, and an app, an agent or a service is built, placed and supervised on machines Praecise operates.