The Agent Was a Folder

How two accounting agents worked without an installed autonomous-agent runtime

By Darryl Wong · 24 August 2026

I run full-stack autonomous-agent platforms on a VPS. They offer the features normally associated with a “real” agent: persistent processes, memory, messaging channels, schedules, tools, and remote access.

Yet for complex professional work, the agents that felt most capable were not those deployments.

They were folders opened in the ChatGPT/Codex desktop app.

I borrowed the filesystem-first idea associated with Vercel’s eve: permanent instructions live in a predictable location, situational procedures live in skill directories, and ordinary files make the agent inspectable and versionable. But I did not install eve in either case. The desktop app supplied the model, tools, file access, interaction loop, and artifact workspace.

This is not a claim that ChatGPT is universally better than self-hosted platforms. It is an experience report about a distinction that became clearer while building these systems:

Agent intelligence, agent definition, interactive harness, and operations infrastructure are separate layers. They do not have to come from the same product.

Two private accounting projects made that distinction concrete. One is a thick deterministic agent system. The other is a thin seven-file operating contract. Neither installs an autonomous-agent runtime, and both have been useful for supervised professional work.

What I mean by “the agent is a folder”

A folder-defined agent might look like this:

agent-workspace/
├── AGENTS.md
├── agent/
│   ├── instructions.md
│   └── skills/
├── knowledge/
├── contracts/
├── evals/
├── scripts/
└── work/

The files supply identity, operating rules, domain procedures, evidence requirements, tests, and working state. Git can show when an instruction changed, which skill was revised, and how the architecture evolved.

But the folder is not necessarily a runtime. It does not automatically provide an event loop, checkpointing, webhooks, authentication, per-session containers, or a messaging gateway. Some other system must interpret the files and do the work.

In my case, that system was ChatGPT/Codex.

The resulting capability came from four layers:

Model
  reasoning · coding · multimodal understanding
        │
Agent definition
  instructions · skills · knowledge · authority boundaries
        │
Interactive harness
  files · shell · browser · plugins · artifact inspection · approvals
        │
Operations runtime
  schedules · queues · channels · persistence · isolation · service delivery

Full-stack platforms bundle much of this. A folder-defined approach lets us choose the source of each layer.

Case study one: a thick financial-statement agent

The first system prepares draft Singapore FRS financial statements for professional review. It is not just a long system prompt. The private repository contains:

• one short permanent instruction contract;
• twelve bounded accounting and document-production skills;
• a deterministic engagement state machine;
• a deterministic accounting and reconciliation engine;
• structured CSV and JSON handoff contracts;
• source and artifact hashing;
• downstream invalidation when upstream evidence changes;
• document generation and package validation;
• PDF rendering and presentation QA; and
• explicit human and auditor authority boundaries.

The workflow is staged:

Intake
  → trial-balance mapping
  → statements and note schedules
  → cash-flow preparation
  → reconciliation
  → disclosure tailoring
  → Word production
  → presentation QA
  → named human approval
  → independent review

Each stage must produce the required versioned artifact before the next stage can pass. Missing evidence blocks the workflow. An upstream change marks affected downstream work stale. The agent may recommend a mapping or accounting treatment, but it cannot grant itself accounting approval, approve the financial statements, or control the appointed auditor’s report wording.

This separation matters. A persuasive model response is not an accounting control.

Deterministic evidence

The repository includes a synthetic non-client demonstration containing:

• 15 zero-difference accounting and cash-flow reconciliation controls;
• 39 evidence-backed disclosure-applicability decisions;
• 29 note-to-statement and movement tie-outs;
• client-specific DOCX generation;
• A4 PDF presentation QA; and
• a final stop at a named-human approval gate.

On 24 August 2026, I reran its regression suite. It executed 41 tests: 40 passed, one end-to-end Word rendering test was skipped because the rendering tools were unavailable in that invocation, and none failed.

The suite tests conditions such as unbalanced trial balances, unapproved mappings, missing disclosure evidence, note differences, artifact tampering, stale downstream work, skipped prerequisites, and approval invalidation.

The architecture is therefore closer to this:

ChatGPT/Codex
  investigation · judgement support · skill routing · human interaction
                         │
Deterministic control plane
  state · hashes · prerequisites · invalidation · approval gates
                         │
Deterministic domain engine
  mapping · schedules · reconciliation · disclosures · document generation

ChatGPT/Codex supplied the reasoning workbench. It did not replace the accounting invariants.

Lesson from case one

For high-stakes professional work, unrestricted autonomy was not the goal. The valuable architecture placed interpretation and investigation in the interactive agent while keeping arithmetic, evidence checks, stage passage, and release authority outside model discretion.

Installing a full-stack runtime could add service infrastructure. It would not automatically improve the accounting logic.

Case study two: a thin corporate-tax agent

The second system is almost the opposite.

It is a portable workspace for preparing draft Singapore corporate income tax computations. Its distribution contains only seven files:

AGENTS.md
README.md
PORTABLE_README.md
agent/instructions.md
knowledge/README.md
evals/README.md
tmp/README.md

It has no reusable tax calculation engine and no embedded approved tax-rule database. The user opens the folder in Codex, identifies an authorized client workspace and Year of Assessment, and asks the agent to prepare or review the computation.

The folder contributes the professional operating contract. It requires the agent to:

• identify the correct Year of Assessment and basis period;
• reconcile revenue and accounting profit or loss to source accounts;
• reconcile brought-forward tax balances to filing evidence;
• distinguish facts, tax rules, assumptions, and reviewer judgement;
• verify current rules against official IRAS or Singapore legislation sources;
• use formula-driven schedules with visible assumptions and checks;
• preserve prior-year and filed documents;
• surface missing evidence and unresolved review points; and
• mark every output DRAFT - FOR REVIEW until approved.

It also prohibits the agent from claiming that a return was filed, making an election, contacting a client, or submitting information without separate authorization and trusted confirmation.

Most implementation capability comes from the host. ChatGPT/Codex reads workbooks and source files, researches current rules, uses installed tax and spreadsheet skills, builds formulas, renders sheets, checks legibility, and discusses uncertain treatments with the human reviewer.

At the time of this review, the private workspace contained three .xlsx output artifacts and three .ndjson execution records across three output folders. Those counts demonstrate workbook-producing usage. They are not a claim of independently assessed tax correctness or completed filing.

The architecture looks like this:

Seven-file workspace
  evidence rules · output contract · confidentiality · authority boundary
                         │
ChatGPT/Codex host
  model · files · Excel tools · web research · rendering · skills
                         │
Human tax professional
  judgement · review · approval · filing authority

Lesson from case two

When the host already supplies strong models, spreadsheet tooling, research, file handling, and artifact inspection, a useful domain agent may require surprisingly little application code.

The folder’s main job becomes governance: define what evidence to use, what output to produce, how to show uncertainty, and where the agent’s authority ends.

This pattern has a real limitation. Reproducibility depends more heavily on the host’s model version, reasoning settings, skills, plugins, context management, and available tools. The folder alone does not create the capability.

Two valid filesystem-agent patterns

The cases sit at opposite ends of a useful spectrum:

Case one is a thick agent with a thinner host dependency. Case two is a thin agent with a thicker host dependency.

Both are legitimate. The correct choice depends on which behavior must be deterministic, reproducible, independently testable, or continuously available.

Why the desktop app felt more powerful than my VPS agents

My VPS platforms remain more autonomous. But the desktop app often feels more capable during complex supervised work because practical capability is multiplicative:

Effective capability ≈
  model reasoning
  × context quality
  × tool quality
  × verification
  × human feedback bandwidth

A platform can have excellent memory, schedules, and messaging while still underperforming if it uses a weaker model, exposes noisy tools, truncates useful context, or makes intermediate artifacts hard to inspect.

The ChatGPT desktop app is designed around parallel projects, files, computer use, plugins, scheduled tasks, and long-running work. In these accounting cases, the tight interaction loop also mattered. I could provide a missing source, inspect a workbook, review a rendered page, correct an assumption, or stop an unsafe path before a small error compounded.

What felt like greater “agent intelligence” was partly model capability and partly a better harness for human-agent collaboration.

What the VPS still does better

This does not make full-stack platforms obsolete. A VPS remains the natural home when the system must:

• remain continuously available;
• receive arbitrary webhooks and external events;
• serve multiple users through stable APIs or messaging channels;
• run private-network automations;
• use custom queues, retries, and service-level controls;
• enforce infrastructure-level tenant isolation;
• use local models or switch providers freely; or
• continue operating without an interactive human workspace.

OpenClaw emphasizes an always-on, multi-channel personal-agent gateway. NanoClaw emphasizes small, understandable multi-agent infrastructure with container isolation. Hermes emphasizes persistent memory, learned skills, messaging, schedules, and provider flexibility. Eve provides a framework for durable sessions, sandboxed compute, approvals, subagents, evaluations, and deployable channels.

Those are operations advantages. They should not be confused with domain intelligence.

The hybrid architecture I now prefer

The useful conclusion is not “desktop or VPS.” It is to assign each layer deliberately:

                    Shared agent definition
             instructions · skills · contracts · tests
                              │
                 ┌────────────┴────────────┐
                 │                         │
          ChatGPT/Codex                 VPS runtime
          reasoning                     schedules
          investigation                 webhooks
          artifact creation             messaging
          human review                  queues and retries
          interactive approval          persistent services

Use the strongest interactive environment for ambiguous work requiring judgement. Put arithmetic and high-risk invariants in deterministic code. Deploy only the workflows that genuinely require continuous autonomy.

The folder can remain the shared source of truth between the cockpit and the engine room.

Conclusion

My experience does not show that ChatGPT is universally better than self-hosted agent platforms. It shows that, for supervised professional work, a strong interactive harness combined with a filesystem-defined domain agent can provide more practical capability than an always-on platform whose model, tools, context engineering, and review interface are weaker.

The first accounting case needed substantial deterministic machinery. The second needed little more than a carefully bounded operating contract. The same host made both useful because it could interpret the folder, access the necessary tools, produce inspectable artifacts, and keep a human professional inside the decision loop.

ChatGPT/Codex is the better cockpit for this class of work. The VPS is still the better engine room. The agent can be the folder that connects them.

---

Method and limitations

This is an experience report, not a controlled product benchmark. The case-study repositories and client materials are private. Architecture descriptions, artifact counts, and test results have been sanitized. No client names, balances, tax positions, or identifying records are included.

Results depend on model selection, reasoning effort, available tools, installed skills, prompt and context quality, task type, and human supervision. The accounting systems prepare drafts for professional review; they are not autonomous accountants and do not independently approve or file financial or tax documents.

Product descriptions are current as of 24 August 2026.

Public sources

• Vercel, Introducing eve
• OpenAI, ChatGPT desktop app
• OpenAI, Long-running work
• OpenClaw, Features
• NanoClaw, What is NanoClaw?
• Nous Research, Hermes Agent