Jim's Book

Why Automate with an Agent

Most automation scripts are brittle because they encode one path through a problem. An agent, given a goal and a set of tools, can recover when the world doesn't match the script — a file moved, an API changed shape, a step failed halfway through. That's the case for reaching for something like Claude Code instead of another shell script: not raw speed, but the ability to route around the unexpected without a human back in the loop every time.

The trade-off is predictability. A deterministic script does the same thing every run. An agent reasons about the situation in front of it, which means testing looks less like "does it produce output X" and more like "does it stay inside the guardrails I gave it."

Automation used to mean removing judgment from a process. Agentic automation means encoding when judgment is needed, and delegating the rest.

Skills & Subagents

A skill is a packaged set of instructions for a recurring kind of task — a deploy checklist, a review rubric, a repo-specific workflow. Instead of re-explaining the same process every session, you write it once and invoke it by name. The agent's default behavior gets replaced by the skill's instructions for the duration of that task.

Subagents solve a different problem: context isolation. A research task that reads fifty files shouldn't fill up the main conversation's working memory with all fifty files' contents — it should return a distilled answer. Delegating that exploration to a subagent keeps the primary thread focused on decisions rather than raw search output.

The two compose well. A skill defines what steps a task requires; a subagent defines who — main thread or delegate — actually does the reading and writing.

Workflows That Fan Out

Some tasks aren't a single conversation — they're a shape: several independent finders searching in parallel, each finding verified by an adversarial check, then a synthesis step that reconciles what survived. Writing that shape as a script, rather than hoping a single agent improvises it correctly, is what makes multi-agent orchestration reliable rather than theatrical.

The pattern that shows up most often is a pipeline with no barrier between stages: item A can be in verification while item B is still being found. Wall-clock time collapses to the slowest chain, not the sum of every stage. Barriers are for the rarer case — deduplicating across every result before an expensive step runs, or short-circuiting when nothing was found at all.

Memory Across Sessions

A session that starts from zero every time repeats the same clarifying questions forever. Persistent memory — a small set of facts about the user, the project, and prior corrections — lets an agent pick up where the last conversation left off, without carrying the full transcript forward.

The discipline that makes this useful is restraint: memory should hold what isn't derivable by reading the current state of the code or the repo history. Preferences, decisions, and the reasoning behind them belong there. File paths and architecture don't — those are one grep away from being wrong the moment the code changes.

Small Habits That Compound

Two habits matter more than any single technique: propose a plan before touching anything that changes shared state, and write down what actually changed afterward. Neither is glamorous. Both are the difference between an agent you can leave unsupervised on real infrastructure and one you have to double-check after every run.

Everything else — which model, which framework, which prompt template — is detail that changes every few months. The habit of checking before acting and logging after acting doesn't.