Agentic Engineering for Operators: The Discipline Behind Agents That Run a Business (2026)

Agentic engineering is the discipline of getting reliable work out of AI agents: you write the spec, the agent does the work, and you verify, review and watch what it ships. Most definitions you’ll find stop at software, where the agent writes code and a developer reviews the diff. I want to push it one step further, because that’s where I live. This post was researched, written, illustrated and published by a Claude Code agent at five past midnight, Bali time, while I was asleep. The fleet it belongs to has logged 1,967 scheduled runs since June 12.

Nothing in that fleet writes an app. It writes blog posts, schedules social media, checks inboxes, finds outreach leads and files tasks for ten businesses. The discipline that keeps it honest is the same one Simon Willison and Addy Osmani describe for code. Only the artifacts change.

Here’s what you’ll get: a plain definition, the vibe-coding contrast, the four habits that make it engineering, what those habits look like when the “codebase” is a business, and the failures that taught me each rule. Every number in here was measured tonight or links to the post where it was.

What Is Agentic Engineering? The Definition Without the Hype

The term is young. Andrej Karpathy, who coined “vibe coding” in February 2025, floated “agentic engineering” in early February 2026 as the name for the professional version. Within weeks it had a working definition from the people who’d been doing it.

Simon Willison’s version is the cleanest: agentic engineering is “the practice of developing software with the assistance of coding agents.” His definition of an agent is even shorter: “Agents run tools in a loop to achieve a goal.” Addy Osmani draws the line by who owns what: the AI does the implementation, and the human owns the architecture, quality and correctness. IBM’s explainer lands in the same place, describing engineers who orchestrate and oversee agents rather than letting them build end to end.

All three agree on the core idea. Agentic engineering isn’t a tool or a job title. It’s a set of habits that turns an agent from something that sometimes produces the right output into something you can depend on.

Here’s my one-line version, from the operator side:

Agentic engineering is designing the spec, the checks and the feedback loop around an agent so that its work is correct when you’re not watching.

The last five words matter most. A developer at a keyboard reviews every diff as it happens. An agent on a cron schedule has nobody sitting next to it. So the engineering has to live in the system: in the instructions it reads, the checks it can’t skip, and the record it leaves behind.

Agentic engineering vs agentic AI

The two terms get mixed up a lot. Agentic AI describes the technology: models that plan, call tools and act over multiple steps. Agentic engineering describes the human discipline of putting that technology to work responsibly. One is the engine. The other is everything that keeps the car on the road.

Agentic Engineering vs Vibe Coding: Same Tools, Different Job

Vibe coding and agentic engineering can use the exact same tool. I could open Claude Code tonight and vibe-code a landing page: prompt, accept, refresh, repeat. The difference isn’t the software. It’s what happens between the prompt and the result.

	Vibe coding	Agentic engineering
Starting point	A prompt	A written spec
Who checks the output	You, by eye, if it looks broken	Automated checks first, then a person
What “done” means	The agent said done	The result was verified in the real system
When it fails	Paste the error back in	Fix the spec so it can’t fail that way again
Memory	The chat history	Versioned instructions plus a run log
Best for	Prototypes, one-off scripts, exploring	Anything that runs again tomorrow

That last row is the honest test. Vibe coding is great when the work is disposable. If you’ll throw it away Sunday night, who cares how it was made? The moment the agent’s output runs again tomorrow, or touches a customer, or spends money, you need the right-hand column.

Osmani makes a point I’d underline twice: testing is the single biggest difference between the two. In his words, without tests an agent “will cheerfully declare ‘done’ on broken code.” I’ve watched that happen with things that aren’t code at all. An agent reports a social post as scheduled when the API quietly rejected it. Another says a database row was updated when the write bounced. Cheerful “done” is the default failure mode of every agent, coding or otherwise.

Is vibe coding bad?

No. I’d argue it’s the right call for maybe a third of what a solo operator builds. The mistake isn’t vibe coding. It’s vibe coding something and then putting it on a schedule. That’s how you end up with a script that’s been failing silently for three weeks.

The 4 Habits of Agentic Engineering

Strip away the vendor diagrams and every serious take on agentic engineering comes down to four habits. Willison, Osmani, IBM’s seven-step workflow and Domino’s practitioner playbook all describe some version of these. They’re listed in the order the work happens.

1. Spec first

You write down what “correct” looks like before the agent touches anything: the goal, the constraints, the inputs, the exact output format. Osmani calls the skipped spec “exactly where projects go off the rails.” A spec doesn’t need to be long. It needs to be specific enough that two different agents reading it would produce comparable work.

2. Verify everything

The agent’s word is not evidence. You check the result in the system where it lives, whether that’s a test suite, the live page or the database row. For code that means tests. For a business agent it means reading back what was written. If the agent says it published a post, fetch the URL. If it says it updated a record, fetch the record.

3. Review before it matters

A person looks at the work before it can do damage, or as close to that point as the job allows. For code, that’s reviewing the PR. For a business agent, it’s an approval queue for anything risky, like a reply to a client or a new outreach campaign.

4. Observe after it ships

Every run leaves a record you can read later, and something reads it. Willison has a line about this I love: LLMs “don’t learn from their past mistakes, but coding agents can, provided we deliberately update our instructions and tool harnesses.” Observation is how you find the mistake, and the updated spec is how the agent learns from it.

Habits 1 and 4 form a loop. You spec, the agent runs, you observe a failure, and you fix the spec so the failure can’t recur. Do that a few hundred times and the spec gets surprisingly hard to break. That loop is the whole discipline.

Agentic Engineering Beyond Code: When the Codebase Is a Business

Every page ranking for this term right now assumes the agent writes software. That’s fair, since it’s where the term came from. But the four habits don’t care what the output is. They work just as well when the agent writes a newsletter, qualifies a lead or reconciles a spreadsheet.

That matters if you’re a solopreneur or a small business owner, because you probably don’t need an agent that writes code. You need one that does the work: follows up with leads, posts consistently, keeps the CRM clean. And the moment that agent runs on a schedule, you’re doing agentic engineering whether you call it that or not. The question is whether you’re doing it on purpose.

Here’s how the software artifacts translate:

Software agentic engineering	Business-ops equivalent	What it looks like in my fleet
Design doc / spec	A written procedure per job	One skill file per job (39 of them); blog-writer’s is 1,190 lines
Unit tests	Read-back checks	Every write is fetched back before the run counts as done
Pull request review	Approval queue	Asana “Drafts (Awaiting Approval)” section
CI / exit codes	A structured result line	SKILL_RESULT: success | skip | fail on the last line of every run
Version control	Backups before self-edits	Timestamped copy of a file before any agent edits it
Production monitoring	A watchdog	A nightly agent that reads every other agent’s result
Concurrency control	Run locks	One lock file per slot per day; first dispatcher wins

None of that is exotic. It’s the same discipline any decent engineering team uses, applied to work that doesn’t happen to compile. If you want the system-level view of how these pieces fit together, I wrote that up in what an agentic OS looks like after 139 days. For how the jobs hand off to each other, see AI agent orchestration without a platform.

What Agentic Engineering Looks Like in One Real Fleet

Theory is cheap, so here’s the actual setup, measured tonight (November 7, 2026). One Docker container per brand. A scheduler fires 20 scheduled skills on a timetable. Each run is a headless Claude Code session that reads one skill file, does the job, logs the result and exits. Nothing listens between runs.

The spec: a skill file per job

The skill file that produced this post is 47,730 bytes and 1,190 lines long. It didn’t start that way. Most of those lines are scar tissue: rules added after something went wrong. Here’s a real one, verbatim:

“The Keywords field is search_volume, lowercase with an underscore, not Search Volume. Verified against the live table 2026-10-06: the title-case spelling returns 422 UNKNOWN_FIELD_NAME and the call yields NO keyword at all, which looks like an empty queue rather than an error.”

That’s what a spec looks like after a few months of agentic engineering. It’s not elegant prose. It’s specific, dated, and it explains why, so the next agent (or the next me) doesn’t “clean it up” and bring the bug back. I break down what belongs in these files in CLAUDE.md best practices.

Change control: backups before any self-edit

Agents in this fleet are allowed to update their own instructions and memory, because that’s how they learn. But they must copy the file first. Tonight’s count: 35 timestamped backups of skill files, 423 of the shared memory file and 380 of the observations log. When an agent edits a skill badly, the fix is one copy command. That’s version control for people who aren’t running git on their ops notes.

Observation: a result contract plus a watchdog

Every run must end with a single line: SKILL_RESULT: success, skip or fail, plus a summary. At 23:35 each night a watchdog agent reads every run’s result and escalates anything that failed. Across the 1,967 logged runs since June 12, the tally is 1,596 success, 216 skip, 44 fail and 2 degraded. Another 109 runs never wrote a clean result line at all.

Here’s the number that justifies the whole design: all 44 failures exited with code 0. Every single one. If I’d monitored exit codes like a normal cron job, my dashboard would show a perfect record. The agent finished the conversation successfully. It just didn’t finish the job.

Review: the honest part

Every post and risky action creates a task in an Asana approval section. Tonight that section holds 234 tasks: 230 still open, 4 closed, and the oldest open one dates from June 15. That’s not a review queue. That’s an audit trail I’m behind on, and I’d rather tell you than pretend.

What actually protects quality here is that the automated checks run before anything goes live, and the human queue is a second look. If your review step depends on a person who’s also running the business, plan for it to slip, and put the gates that really matter where they can’t.

If you’d like help designing that kind of system for your own operations, without the five months of scar tissue, you can book an automation strategy session with me. I’ll show you exactly how this fleet is wired.

The Failure Modes That Taught the Rules

Every rule in a practice like this should trace back to a specific failure. If it doesn’t, it’s probably ceremony. These are the ones that shaped mine. The full list of nine unattended practices lives in Claude Code best practices from 4 months of unattended runs, so here I’ll stick to the pattern behind them.

That pattern is the success-shaped error: a response that looks like success to every layer that checks it, while the actual work didn’t happen.

The API that said “OK” while refusing

Our SEO data provider returned 40200 Payment Required nested inside an HTTP 200 response whose top-level status read 20000 Ok. The account had run dry. Every retry tool, every status check and every “did the call succeed?” test said yes. The fix wasn’t a smarter retry. It was a rule in the spec: ignore the envelope, assert on the per-task status code, and check the account balance before starting.

The database that read fine and wrote nothing

Airtable field names are case-insensitive in filter formulas but case-sensitive in write payloads. So the agent could read the Keywords table perfectly and then fail every status update with a 422 it treated as a minor warning. By October 31, 56 of 128 rows marked Published had no publish date. Nothing crashed, and the data just slowly went wrong. The fix was the dated note you saw above, plus a read-back after every write.

The exit code that always said yes

That’s the 44-for-44 above. An agent session exits cleanly even when its job failed, because from the runtime’s point of view nothing went wrong. The fix is a result contract the agent must write and a watchdog that reads it.

The memory that kept growing

This one’s still open. The shared memory file where agents record what they learn is now 2.38 MB and 10,257 lines. No agent reads all of it. Each one reads the newest entries and greps for the rest. It works, but it’s a warning sign: memory without pruning becomes a junk drawer. Agentic engineering includes maintaining the instructions, not just adding to them. I’ll report back when I’ve fixed it.

Notice what these failures have in common. None of them would be caught by a smarter model. All of them are caught by an engineering habit: verify the real result, write down the rule and date it, then watch the next run.

Agentic Engineer Skills: What You Need and What You Can Skip

“Agentic engineer” is already showing up as a job title, and course sellers are lining up behind it. Before you buy anything, here’s the honest skills list from someone who runs agents for a living.

Skills you actually need

• Writing precise instructions. This is the core skill. If you can write a procedure a new hire could follow without asking questions, you can write a skill file. If you can’t, no framework will save you.
• Thinking in failure modes. For every step, ask: “How would this fail without anyone noticing?” Then add a check for that.
• Reading logs and API responses. You don’t need to write the integration. You do need to look at a JSON response and see that status_code says 40200 even though the envelope says OK.
• Basic scripting. Enough shell or Python to read a file, call an API with curl and check a value. Agents write most of it, but you have to be able to read what they wrote.
• Knowing your business process. This is the one engineers underrate. An agent can’t encode a process you can’t describe. Domain knowledge is the spec.

Skills you can skip (for now)

• Agent frameworks. My fleet runs on plain skill files, curl and a scheduler. I measured why in MCP vs CLI: tonight’s whole pipeline makes zero MCP calls.
• Multi-agent architectures. Most business jobs are one agent doing one job on a schedule. Coordination is handled by timing and locks, not agents negotiating with each other.
• Prompt-engineering tricks. Clear, specific, dated instructions beat clever phrasing every time.
• Certifications. A running system with logs proves more than a badge. If you’re hiring, ask to see the logs.

If you’re starting from zero, begin with the Claude Code tutorial for beginners, then read Claude Code agents in production to see where it leads. Pick one boring, repeatable job and put it on a schedule with a result line. That’s your first piece of agentic engineering.

Agentic Engineering FAQ

What is agentic engineering in simple terms?

It’s the discipline of getting dependable work out of AI agents. You write a clear spec, let the agent do the work, check the result in the real system, review risky output, and keep a record you can learn from. The term started with software development, but the same habits apply to any work an agent does.

Who coined the term agentic engineering?

Andrej Karpathy suggested it in early February 2026 as the professional counterpart to “vibe coding,” which he’d coined a year earlier. Simon Willison and Addy Osmani wrote two of the most cited definitions shortly after.

Is agentic engineering just vibe coding with extra steps?

The extra steps are the point. Vibe coding accepts the output if it looks right. Agentic engineering verifies it, records it and fixes the spec when it’s wrong. One gives you a demo, and the other gives you something you can leave running.

Do I need to be a developer to practice agentic engineering?

Not for business operations. You need to describe your process precisely, read basic logs and think about how things fail. Light scripting helps. Most of my fleet’s skill files are plain English with a few curl commands.

What’s the difference between an AI coding agent and agentic engineering?

The coding agent is the tool, like Claude Code, Codex or Gemini CLI. Agentic engineering is how you use it. I compare the tools themselves in what is an AI coding agent.

How do I start with agentic engineering for my business?

Pick one repetitive task that runs at least weekly. Write a one-page spec for it. Have an agent run it, and add one read-back check and one result line. Watch ten runs before adding a second task. Most people try to automate five things at once and can’t tell which one broke.

Final Thoughts: Agentic Engineering Is a Habit, Not a Title

Agentic engineering isn’t about which agent you pick. It’s about what you build around it: a spec specific enough to follow, checks the agent can’t talk its way past, a review step for anything risky, and a record that turns every failure into a better spec.

The software world got there first, and its definitions are good. But the bigger opportunity is that the same discipline lets one operator run real business operations on agents, and not as a demo. This post is one of 1,967 runs that prove it can work, and the 44 failures inside that number are why I trust the other runs.

Start small. One job, one spec, one result line, one check. Then let the failures write the rest of your rules.