A repository is unusually friendly terrain for an agent. Its files are structured, Git gives us history and rollback, and tests can object when the agent is wrong. We call them coding agents because repositories already supply that structure.
Outside a repository, we have to provide it ourselves. Many awkward workflows can still be described as files, tools, rules and feedback, but somebody has to decide what the agent may read, what it may change and how we will spot a mistake.
Skills Connect the Existing Pieces
A reusable agent skill may be only a short document: when a procedure applies, which tools to call, in what order and how to check the result. It can sit beside scripts, templates and examples. When the skill runs, the calendar still stores events, Trello still coordinates the team and Obsidian still holds the notes.
Claims about an agent replacing five applications tell me very little. I would rather know which systems a morning review reads, what it writes and where it waits for a person. That description gives us something we can inspect and improve.
This pattern works best when:
- the inputs are available through files or narrow APIs;
- the output has a clear format;
- mistakes are cheap or require approval before they escape;
- the procedure benefits from context spread across several sources;
- a human currently wastes time copying information between tools.
It works badly when correctness is hard to observe, authority is broad, or the dedicated application’s interface is already faster and safer.
From Notes to a Working Routine
We met Teresa Torres’s layered context system in the memory chapter. Her Obsidian and Claude Code workflow is worth returning to for a different reason. Tasks remain Markdown files with structured metadata. A /today procedure collects due and overdue work into a daily view. Separate scripts gather research, while Torres decides which papers deserve attention.
The procedure leaves a useful trail. We can inspect a task, change the tag rules and trace the daily view back to its sources. The selection of research also remains a human decision instead of disappearing inside an automated summary.
The same arrangement can answer questions that span notes, tasks and calendar events. It might prepare a project brief from scattered decisions, find unresolved commitments after a meeting, or draft a weekly review with links to the evidence. A sensible file structure and a procedure precise enough to rerun will take us quite far.
The costs are familiar: personal notes contain sensitive material, and broad vault permissions can expose far more than the current task requires. Automatic rewriting can also damage carefully maintained links or metadata. I would start read-only, limit the directories in scope and use versioned storage before allowing changes.
Joining Product Questions to the Code
Much of the work around implementation consists of joining material that lives in different places: grouping customer feedback, tracing a request to the relevant code, drafting acceptance criteria, comparing a proposed feature with existing behaviour, or preparing a small experiment.
I would be wary of calling the result an “AI product manager”. The model has no relationship with the customer, no accountability for the bet and no privileged understanding of the market. It can process the material that a product manager or engineer provides, which is useful enough without inventing a job title for it.
Where it earns its keep is in connecting a product question with implementation evidence. A product owner can ask where churn is calculated, which events feed the metric and what a reversible experiment would touch. The agent can then produce a prototype, tests and a list of assumptions. That gives the team something more concrete than a requirement written in isolation. It still leaves somebody accountable for deciding whether the experiment is ethical, worthwhile and interpretable.
Research needs the same restraint. An agent can find and classify sources quickly, but six weak articles still make a weak evidence base, however confident the summary sounds. I would preserve links, separate primary from secondary evidence, record search limits and keep consequential conclusions reviewable.
Scheduled Work Changes the Risk
A local agent stops when its laptop sleeps. On an always-on machine, the same procedures can run on a schedule or in response to events.
Chris Parsons’s VPS setup, mentioned earlier in this series, includes writing and repository work alongside personal automation. He synchronises a vault, exports session logs and runs a periodic reminder check which can send Telegram messages. The move from interactive tool to operation is quite mundane: a scheduler, a prompt, files, credentials and a notification script.
Every part can fail. The machine needs patching, logs and costs need limits, and a retried reminder may be sent twice. Parsons also notes that his heartbeat prompt accumulated jobs until it became slow and difficult to reason about; he plans to split it into focused jobs.
Persistent access also removes a healthy boundary. Parsons makes the point directly: when work is available from a phone, every spare moment can become a work session. The tool does not protect downtime. We have to decide where automation stops, not only where it can reach.
For scheduled work I would insist on the same boring controls used for production services:
- one narrow responsibility per job;
- a dedicated identity with the minimum permissions;
- idempotent operations where retries are possible;
- a run log that records inputs, decisions and external changes;
- explicit cost and retry limits;
- failure notification that does not depend on the failing agent;
- a simple way to disable the job.
Cron has the virtue of being understandable.
Scheduling changes the permission problem too. Public accounts of always-on agents range from summarising team stand-ups to managing home media and diagnosing servers. The OpenClaw community thread is a collection of first-person anecdotes rather than controlled evidence, but the concerns are recognisable: credentials, monitoring, unexpected network access and running cost.
An agent with SSH can attempt server recovery; calendar credentials allow it to create real commitments; access to chat, issue tracking and source control is enough to assemble and publish a stand-up summary. Once the agent can act while nobody is watching, I want narrower credentials and stronger auditability than I would give an interactive session.
Where a service supports it, I would give the agent its own identity, begin with read access and put approval immediately before consequential external changes. Secrets should stay outside generated scripts. Revocation should be quick, and recovery should work without help from the agent which caused the problem.
A Second Agent Can Be a Useful Reviewer
The earlier workflow chapter introduced Jamon Holmgren’s Night Shift workflow. One detail is relevant beyond coding: he assigns separate review agents six concerns, including architecture, domain behaviour and the human experience. They inspect the plan before implementation and the resulting diff afterwards, using specifications, documentation, tests and commits as shared state.
This example still concerns code, but the pattern is reusable. A second agent can check a research digest against its citations, sample support classifications against the taxonomy, or trace the conclusions in a weekly operational report back to metrics and logs.
Independence matters. Two agents using the same vague instruction may agree on the same mistake. Give the reviewer a separate rubric, source material and authority to reject the result. Where possible, include deterministic checks rather than relying on a second opinion expressed in fluent prose.
Reviewers are not free. Parallel workers duplicate effort, produce more output to inspect and may make conflicting edits. I would add one when it owns a distinct concern and has a real basis for rejecting the work.
When the Dedicated App Wins
Once a few skills work, it is tempting to turn every routine into an agent conversation. I do not think that is a useful default.
A dedicated application is often the better choice when it provides:
- a fast interface for a frequent, predictable action;
- transactions and conflict handling that would be tedious to reproduce;
- mature permissions, audit and recovery;
- shared conventions that other people already understand;
- reliable behaviour without paying a model to rediscover the procedure.
I would use an agent at the seams: where information crosses systems, where the input is messy, where the procedure changes often or where the required context is too broad for a fixed form. Stable operations with well-understood inputs usually belong in ordinary software. Most useful systems will contain both.
Markdown procedures are useful at these seams because the unstable part remains visible. We can read the instruction, version it, test it and replace it when the workflow changes, while leaving the stable application alone.
Where I Would Use One
Part I began with getting useful code from an agent. It ends with the machinery around the model: context, memory, procedures, review and feedback. I now ask which parts of a workflow can be made explicit, observed and safely rerun. The agent needs a bounded job, sufficient context and narrow tools; ambiguous or costly decisions stay with a person.
Part II begins with letting go without losing control, where those procedures have to work without constant approval. Parts III and IV then follow that change into multiple agents and the limits of human coordination.