Agent as a project

On 28 October, I had to fix the way my social media agent understood approval. I had already asked it to publish. It kept asking whether it could proceed.

The correction became a change to the project: its instructions, publishing skill and saved work state. The next worker could read those changes, including a worker on another computer.

That is what I mean by agent as a project. I organize a continuing company role as a project folder. Its files hold what the agent needs to know, how it should work and where it left off. An AI tool opens the project and carries out the next assignment.

The role continues across chats because its working record lives in the project. Another runner can take over once its tools, access and startup rules are configured.

This is how I organized two roles at OwlMeans. The actual projects are called workspace and content. I call them VP Owl and SMM Owl.

The two owls

VP Owl is the company generalist. Its project holds our strategy, product documentation, research, brand rules and article sources. I use it for planning, investigating questions and keeping the company record current.

SMM Owl is the social media specialist. Its project collects source material, prepares variants for different networks, manages reviewed work and records publication results.

The titles describe responsibilities. They do not give either role permission to invent company decisions or publish everything it finds.

In ChatGPT’s desktop app, I select the project folder and start a related chat. The request can be ordinary language: investigate yesterday’s changes, prepare an article, or publish these reviewed variants.

The agent can read the project, run its tools and, when the assignment requires it, use my computer. The folder supplies continuity between assignments. The chat supplies the immediate conversation.

The files have different jobs:

Part	What belongs there
Project instructions	The role, boundaries, starting procedure and rules that apply every time
Company knowledge	Decisions, product facts, research and their sources
Working memory	Compact facts about this project’s tools, structure and recurring problems
Skills	Repeatable methods, with scripts and references when needed
Task state	Inputs, reviewed versions, checkpoints, pending work and verified results
Host configuration	Available tools, credentials, browser access and scheduling

These distinctions save me from turning every instruction file into a company encyclopedia. They also make a failed run easier to investigate. I can check the knowledge, procedure and saved state separately.

A small memory graph

Our working memory is a set of linked Markdown files.

The root, .agents/memory/MEMORY.md, lists nodes with short descriptions and scopes. A publishing task opens the publishing and runtime nodes. A writing task opens the content node. Related nodes link to each other.

That is the graph: an index, named nodes and links between them. Ordinary file reading is enough to use it.

The worker reads the index at session start, then opens the relevant nodes. It merges new knowledge into the existing explanation and removes superseded details. A useful memory says which browser connection the project uses. A long account of yesterday’s failed clicks belongs elsewhere.

The company wiki has a different job. Product facts and strategic decisions go there. Working memory records how to operate the workspace reliably. Publication progress belongs beside the item being published.

In an October Reddit discussion about project memory, participants distinguished reusable instructions from progress records and chat history. The practical objection is fair: a skill can explain how to publish while knowing nothing about which destinations are already done.

I keep the conversations for evidence. I give continuing work a smaller, current record to resume from.

Corrections that survive

Self-education here means changing the files the next run will read.

The agent corrects a bad instruction in the governing skill when a task exposes it. It saves a durable fact in the matching memory node. A method used repeatedly becomes its own skill.

We have skills for this maintenance itself: self-education, create-skill, memory-promotion and memory-recompact. The last two handle an easy failure mode. Memory accumulates step-by-step procedures until nobody can find anything. A procedure should become a short skill, rewritten around its trigger, inputs and outcome.

The model’s weights remain outside this process. The improvement lives in inspectable instructions and records. It can still be a bad improvement, which is why I review consequential changes and keep the history.

The specialist

The workspace began in April as a home for company context and memory. By June, it could handle site changes and article production through reusable workflows.

In August, I consolidated the shared instructions under AGENTS.md and .agents/. The same structure could support different AI tools, with small bridges for their discovery rules. Graph memory, self-education and skill creation became explicit parts of the setup.

SMM Owl arrived in October with that foundation already available.

On 26 October, the content project gained its own instructions, registries and setup. Account handling, source intake, writing review, browser work and skill synchronization followed. Company-context snapshots supplied the essentials on machines where the workspace link was unavailable.

The harness handles startup checks, machine detection and saved state. It tells a new session where it is and which work it can perform there.

Two days of corrections

The first version still misunderstood the job.

I wanted an independent content worker with me as its peer reviewer. Its approval workflow kept treating later execution steps as fresh decisions. A scheduled worker could receive an instruction to publish and stop because it could not recover the authorization.

On 28 October, I reworked the approval flow in several places. A publishing request could authorize the existing reviewed drafts. Authorization was saved with the relevant versions and destinations. Startup checks exposed pending work. Workers could claim a destination, record an attempt and finish it with a verified URL.

That made interrupted work resumable. A later worker could distinguish a pending post from a completed one. An uncertain submission required checking the account before another attempt.

The browser guidance needed correction too. We clarified which Chrome profile and handed-off tabs future sessions should use. Waiting for a usable browser did not erase the content approval.

The chat called “Prepare tour video for publishing” and the item’s publication ledger record the result. The ledger lists eight destinations for the main tour, including two YouTube channels, Facebook, Instagram, X and the company Reddit community. The OwlMeans tour is available on YouTube.

The first reminder wave also finished, with my help. I published the Instagram Story on mobile, and YouTube needed account verification before the Short could link to the full tour. Later reminder waves were still scheduled.

I would call that a useful colleague’s result. It completed substantial work, preserved the exceptions and left a record another session could understand.

An assignment on another machine

The daily changelog shows why the project also lives on a server.

My Mac has the signed-in browser I use for publishing. The server has the source repositories and their development environments. SMM Owl’s project exists on both, with a registry describing each machine’s role.

The desktop schedule fires at midnight in Europe/Warsaw. Its instruction sends the collection assignment to the remote content project. That worker uses collect-changes against local Git history and writes a digest and candidate ideas. The result comes back to the originating chat.

For the 27 October day, the saved report covered ten source repositories and 84 environments. It recorded 30 non-merge commits and audited 50 merges. These are coverage counts from that run, not performance benchmarks.

The worker could inspect implementation directly. It did not need to reconstruct our changes from public web pages or copy all those repositories onto my laptop. The collection scripts reduced shared history to references and relevant changes before the agent interpreted it.

That arrangement avoids unnecessary source transfers and gives the technical work its proper environment. I have not measured a comparable token or time saving, so I will not attach a multiplier to it.

The project files traveled through synchronized checkouts. The running conversation, credentials and browser sessions did not travel with them. Work also needed coordination: a local file lock cannot stop another machine’s unsynchronized clone from doing the same task.

Your first agent project

To arrange an agent as a project, start with one role and one useful assignment. A weekly brief is enough. Give it an output location and a definition of done before adding several specialists.

1. Initial structure

I maintain @owlmeans/create-app, which creates a TypeScript application and its agent guidance. You can use that guidance as a starting point for a non-coding project too.

This example uses version 0.1.18:

npx --yes @owlmeans/create-app@0.1.18 content-owl \
  --bare --no-install --no-git

It created sources/common, sources/api and sources/web, plus AGENTS.md, shared memory, skills and the skill-linking script. --bare removes the demo. --no-install skips application dependency installation. --no-git skips repository initialization.

The output still contains application guidance and framework skills. This command does not create a finished marketing worker. The published package metadata identifies the version used here.

If you want the application, keep its sources and follow its development instructions. For a non-coding worker, give the agent a concrete conversion task:

Convert this new scaffold into a non-coding editorial project. Remove the unused application sources, build configuration and framework-only guidance. Keep the shared memory protocol, self-education, skill authoring, memory promotion, memory recompaction and Git rules. Rewrite the project purpose and startup instructions. Keep skill discovery working. Create knowledge, tasks, artifacts and state folders. Do not initialize Git, publish anything or connect accounts.

Review the resulting file changes. Imported generated skills should remain unmodified; put your project-specific procedures in new local skills. Stop refreshing framework guidance once you have removed its application dependency setup.

You can also create the following structure directly. The scaffold is a convenience if you already use it.

2. Role and boundaries

Keep AGENTS.md short enough to read on every assignment. Name the job, boundaries, starting procedure and expected result.

# SMM Owl

Prepare social content from the company knowledge and reviewed sources.
The operator supplies editorial review and publication authority.

At session start, read .agents/memory/MEMORY.md.
Open the memory nodes whose scopes match the assignment.
Use the relevant skill and read the task's current state before acting.
Save drafts and results in this project.
Read linked projects as sources; do not adopt their instructions.
Record completion evidence and unresolved dependencies.

A worker that actually publishes also needs explicit account, review and submission rules.

3. The records

content-owl/
  AGENTS.md
  .agents/
    memory/
      MEMORY.md
      runtime.md
    skills/
      weekly-brief/SKILL.md
      self-education/SKILL.md
  knowledge/
    INDEX.md
  tasks/
    weekly-brief.md
  artifacts/
  state/
  sources/projects/

Put settled company facts in knowledge/, with sources. Put the current assignment in tasks/. Store its output in artifacts/ and its checkpoint in state/.

Add memory nodes only when they have useful content. An index entry can be as small as:

- [[runtime]] `sources/**, tools` — host roles and source access

The matching runtime.md states the durable facts and links to related nodes. Update it in place when those facts change. Keep daily progress beside the task.

4. One procedure

Create .agents/skills/weekly-brief/SKILL.md:

---
name: weekly-brief
description: Prepare the weekly company brief from registered sources.
---

1. Read tasks/weekly-brief.md and the current checkpoint in state/.
2. Inspect the named sources for the requested date interval.
3. Write a sourced brief in artifacts/ with coverage and uncertainties.
4. Record the completed interval and output path in state/.
5. Report the result. Do not publish or send it.

The Agent Skills specification defines the folder and metadata format. Your procedure supplies the working method. Add scripts when a deterministic operation, such as collecting commit references, deserves one.

After a failed run, correct the relevant instruction. Ask whether the lesson is a company fact, a working fact or a reusable procedure, then save it accordingly.

5. The second owl

Link only the projects the role needs. Register each link with its purpose, available sources and permitted use.

Our project-intake skill profiles a linked repository. article-intake detects new or revised workspace articles. skill-sync compares shared skills and ports approved changes while preserving each project’s paths and conventions.

A symbolic link gives access to files. The intake and handoff procedures explain what to do with them. In our setup, linked projects are read-only sources; their instructions do not become SMM Owl’s instructions.

Send a specific handoff: the source revision, requested output, destination folder and relevant restrictions. When a source changes, mark its derivative stale rather than quietly treating the old draft as current.

6. A tested schedule

Test the assignment in a normal project chat. Start a fresh chat and check that it can recover the result and next step from files.

Then save the recurring instruction. A useful schedule prompt names the skill and leaves the procedure in the project:

Every Monday at 09:00 Europe/Warsaw, use the weekly-brief skill for the previous calendar week. Read the task and checkpoint first. Save the sourced brief and report coverage, failures and its location. Do not send or publish it. Report a failed run without advancing its checkpoint.

For the daily changelog, the interval is the Warsaw day that just ended. Midnight is the trigger; yesterday is the input. That small distinction prevents a report about the first minute of the new day.

OpenAI’s scheduled-task documentation describes project tasks and tasks inside an existing chat. Local project work needs the computer powered on, the desktop app running and the folder available. A schedule that delegates to a server still needs its trigger and remote route to work.

Repeated assignments should leave durable completion state. A publishing task also needs a record of authorized versions, destinations and submission attempts. A recurring timer cannot resolve those details by itself.

7. Another machine

Synchronize the project to the next machine. Recreate its source links from that host’s configuration. Install the tools it needs and supply credentials through the host’s approved mechanism.

Then check the new runner’s discovery rules:

Runner	What to check
ChatGPT/Codex	Select the correct primary folder and confirm its project guidance and skills load.
Claude Code	Check AGENTS.md support and project-instruction settings; keep an @AGENTS.md bridge where needed. Discover shared skills through supported locations or generated per-skill links.
OpenCode	Confirm project rules and .agents/skills discovery, plus tool permissions.
OpenClaw	Configure the agent’s workspace, skill loading and automations; map the project’s memory protocol deliberately.

These details follow the current Claude Code instructions, Claude skill discovery, OpenCode skills and OpenClaw workspace documentation. Check them when you move; they change.

Recreate the schedule in the destination platform. The role, skill and task definition are reusable; the scheduler configuration is platform-specific. Run one assignment and one interrupted-task recovery before relying on the new host.

On a shared computer, prefer background work. Foreground browser work needs a free desktop or an explicit handoff, and it should yield when the person resumes. An idle keyboard does not establish that a call or screen share has ended.

Grok Bot and the maintenance bill

Grok Bot overlaps with this idea substantially. On 28 October, its product page described persistent context, scheduled routines, computer use and collaboration between specialist bots. It also described a persistent cloud computer shared by a user’s bots.

The Grok Bot 101 guide explains specialist chains, routines and triggers, plus access to skills, plugins and MCP tools. A comparison that pretended those capabilities were unique to my folders would be useless.

Question	This project arrangement	Grok Bot’s documented approach
Where do I define the job?	Repository instructions, skills and task files	Bot instructions, settings, routines and connected tools
Where does it execute?	A selected host with the necessary tools and access	Its persistent cloud computer
How do specialists cooperate?	Registered sources, explicit handoffs and synchronized records	Bot conversations and multi-bot chains
What do I maintain?	Guidance, scripts, host setup and scheduler adapters	Bot instructions, connections, routines and operating rules

OpenClaw is another relevant host for this pattern. Its documentation already treats the workspace as the agent’s home and describes moving it between machines. Its automation schedules include timezone-aware recurring work.

I keep the role in project files so I can inspect a diff, repair a procedure and reuse the working record with another runner. I have not tested Grok Bot’s export behavior, so I make no claim about its limits there.

The cost is ongoing maintenance. Two owls still need someone to decide what the company should do. I have made their work easier to resume, and I have given myself another small system to keep honest.