ai/
A Year of Agent Engineering - Rules, Skills, Workflows, and Loops
Andrei Bespamiatnov
Author
The year that changed the question
A year ago, most teams I worked with still treated AI as a chat window. Someone pasted a stack trace, got a plausible answer, and then re-typed the useful bits into the repo by hand. That can teach a person. It does not scale a team.
The question that actually mattered was different: how do you make an agent repeatable? Not clever once. Repeatable across people, repositories, and weeks.
I spent that year writing rules, packaging skills, wiring workflows, and running loops that were allowed to fail closed. This post is the shape that survived.
Four artifacts, four jobs
If you only have prompts, everything becomes a prompt. That is how you get a 400-line system message that nobody dares to edit.
| Artifact | Job | Changes when |
|---|---|---|
| Rule | Always-on constraints. The agent must not do X. | Policy, safety, house style |
| Skill | How to do a kind of work. Review this kind of doc. Open this kind of PR. | A practice stabilizes |
| Workflow | Ordered steps across tools. Fetch, classify, write, hand off. | The path is known |
| Loop | Repeat until a stop condition. Test, fix, re-test. | The outcome is checkable |
A rule is not a skill. A skill is not a loop. Mixing them is the usual failure mode: a “skill” that secretly contains a whole CI pipeline, or a “loop” with no stop condition except token budget.
Rules are cheap to ignore if they are vague
A useful rule is short and testable.
- “Do not invent ticket IDs.”
- “Do not commit secrets.”
- “If the build is red for a reason you did not introduce, stop and report.”
A useless rule is a vibe: “write clean code” or “be a senior engineer.” Agents already try to sound senior. They need fences.
I keep rules in the repo, next to the code they govern, and I review them like code. If a rule only lives in one person’s head, it is not a rule. It is folklore.
Skills are procedures you are willing to reuse
A skill is a procedure with a trigger. “When the user asks for an architecture review, follow this section order.” “When generating a catalog README, use this folder shape.”
The test of a skill is whether a second person can run it next month without asking you what you meant. That usually means:
- A clear trigger (“use this when…”)
- A hard stop (“do not also…”)
- Inputs and outputs named in boring language
- No client names, no environment gossip, no “you know the one”
I have thrown away more skills than I have kept. The ones that survived were the ones I ran twice in anger.
Workflows are for when the path is known
A workflow is a sequence you already believe in. Pull the top exceptions. Map each one to a repository. Open a working folder. Write an analysis, then a plan, then a classification.
Workflows fail when people hide branches inside prose. If step 3 is “maybe also check the database unless it is Friday,” you do not have a workflow. You have a story.
Write the happy path as a list. Put the exceptions in a table. If you cannot, you are not ready to automate it.
Loops need a reason to stop
This is the part teams skip.
A loop that “keeps fixing until it looks good” will burn money and invent scope. A loop that is safe has three explicit exits:
- Done. The check you named is green. A failing test you added now passes. The classifier said “infrastructure, not code” and you stopped.
- Cap. N iterations, then a written “could not reproduce” or “needs a human.”
- Refuse. The change would touch secrets, production config, or a surface the agent is not allowed to own.
Classify before you fix. A surprising number of “bugs” are expired certificates, a dependency the agent cannot see, or a host that is down. If the first step is git checkout -b, you have already wasted a loop.
What I would not automate
I do not let a loop decide product intent. I do not let it rewrite a public contract because a test was annoying. I do not let it “just push to main.”
Agents are excellent at the middle of a known path. They are poor at noticing that the path is the wrong one. That is still your job.
A small operating model
If you want a starting kit for a team:
- Write five rules that would embarrass you if they were broken in public.
- Promote one procedure you already run by hand into a skill.
- Turn one multi-step path into a workflow with named artifacts.
- Add a loop only where a machine can see the stop condition (tests, lint, a classifier label).
Do that for a quarter. Then delete half of it. The remainder is your real agent engineering practice — not the demo, not the slide, the parts that still run when you are tired.