---
title: Agentic engineering, gently
description: An agent is a model running in a loop, choosing tools until a goal is met. Agentic engineering is the work of making that loop reliable, affordable and safe. You already do most of it; this page gives you the words.
author: Asem Abdo
course: Agentic Engineering
lesson: Agentic engineering, gently
url: https://openplanr.dev/learn/agentic-engineering/gently
updated: 2026-10-17
related:
  - https://openplanr.dev/learn/agentic-engineering.md
  - https://openplanr.dev/learn/agentic-engineering/agent-loop.md
---

# Agentic engineering, gently

By [Asem Abdo](https://www.linkedin.com/in/asemabdo/) · Updated 2026-10-17

*The big idea*

An agent is a model running in a loop, choosing tools until a goal is met. Agentic engineering is the work of making that loop reliable, affordable and safe. You already do most of it; this page gives you the words.

**Chapter 1 · the shift**

## From prompting to engineering

> **Two engineers, same model**
>
> Both use the same model. The first types requests into a chat and copies the answers. The second gives the model a short project brief, a set of tools with clear names, a rule that blocks edits to migration files, a test command it must run before it says "done", and a budget of 40 steps. The second engineer gets work that is better, cheaper and checkable. Nothing about the model changed. **The system around it did.** That system is the harness, and designing it is agentic engineering.

### Where the name comes from (2025 to 2026)

In February 2025 Andrej Karpathy named "vibe coding": accept what the model writes and stop reading the code. A year later he proposed **agentic engineering** for the professional version: "agentic" because you are mostly orchestrating agents and acting as oversight rather than typing code, and "engineering" because doing that well is a learnable expertise. The difference is not how much the agent writes. It is whether you design, constrain and verify what it does.

**Vibe coding** (great for prototypes)

- Accept output, rarely read it
- Success means "it seems to work"
- No budget, no gates, no evals
- Breaks down at production scale

**Agentic engineering** (built for production)

- Agents write most code; you design the system
- Success is defined by checks: tests, types, evals
- Rules are enforced in the harness
- Cost, time and quality are measured

> **One sentence to own:** Agentic engineering is software engineering where one component is non-deterministic, so the design work moves to context, tools and verification.

**Chapter 2 · the words**

## Fourteen terms in plain language

- **Agent:** A model that decides its own next step and calls tools in a loop until it is done. Used: a coding agent fixing a failing test on its own.
- **Workflow:** Fixed steps you wrote in code; the model fills in each step but does not choose the path. Used: summarize, then classify, then store.
- **Tool:** A function the model can ask your code to run, described by a name, a description and an input schema. Used: read_file, run_tests, search_docs.
- **Context window:** Everything the model can see in one call, measured in tokens. Used: the context meter in your agent's status bar.
- **Harness:** Everything around the model: prompt, tools, permissions, memory, hooks, context management, orchestration. Used: Claude Code, Codex and Cursor are harnesses.
- **Context engineering:** Curating the smallest set of high-signal tokens the model sees at each step, and when they arrive. Used: a skill that loads only when the task matches.
- **Harness engineering:** Designing the guides and sensors around an agent: instructions, tools, permissions, hooks, tests. Used: a hook that blocks edits to generated files.
- **Loop engineering:** Designing the goal, checks, stop condition and budget so an agent keeps working toward a result without a human prompting every step. A young term. Used: "fix until all tests pass, max 10 rounds, max $3".
- **Hook:** Code that runs at a fixed point in the agent's lifecycle and can block, inject or log. Used: a PreToolUse hook that stops migration edits.
- **Subagent:** A separate agent with its own clean context, started by a parent agent with a written brief. Used: exploring a codebase without filling the main window.
- **MCP:** An open protocol that exposes tools and data to any compatible agent. Used: a Linear or Slack server your agent can call.
- **Eval:** A repeatable test that scores agent output, so you can compare before and after a change. Used: 30 real support questions with known good answers.
- **Model tiering:** Sending each task to the cheapest model that does it well. Used: strong model plans, cheaper model executes.
- **Human in the loop:** A person approves at defined checkpoints where mistakes are expensive. Used: review gate before a merge or deploy.

**Chapter 3 · bridge from what you know**

## You already know the shapes

Every agentic concept has an ancestor in ordinary backend engineering. Use the left column to remember, the right column to speak.

| Concept you already know | Agentic equivalent | What changes |
| --- | --- | --- |
| API endpoint with a DTO | Tool with an input schema | The caller is a model, so names and descriptions are the documentation it reads. |
| Middleware (guards, interceptors) | Hooks | They wrap tool calls instead of HTTP requests, and can block or inject context. |
| Environment config and feature flags | System prompt, AGENTS.md or CLAUDE.md, settings | Config is read by a model that may ignore it, so critical config moves into code. |
| RBAC and least privilege | Permission modes and tool allowlists | The actor is non-deterministic, so defaults must be tighter. |
| Unit and integration tests | Evals | Outputs vary, so you score a set of cases instead of asserting one exact value. |
| CI pipeline | Regression evals plus headless agents in CI | Every prompt or harness change reruns the eval suite. |
| Logs, APM, tracing | Agent traces: steps, tokens, cost, latency | You trace reasoning steps and tool calls, not just requests. |
| Queue workers | Subagents and fan-out | Each worker needs a written brief, and the brief can lose information. |
| Caching layer | Prompt caching | Stable prompt prefixes are cached by the provider; order your prompt for it. |

**Chapter 4 · the first decision**

## Workflow or agent?

The first senior move is to not build an agent when a workflow will do. Autonomy costs predictability, money and debuggability.

- "The steps are always the same: extract, classify, store." → **Workflow**: Fixed path, easy to test, cheapest.

- "I can't know in advance which files need to change." → **Agent**: The path depends on what it finds.

- "Mostly fixed, one step needs judgment." → **Workflow with one agentic step**: Autonomy only where it pays.

```python check=run title="A workflow: the code chooses the path, the model only fills steps"
def model_step(task, text):
    return {"summarize": text[:20] + "...", "classify": "billing"}[task]

def workflow(ticket):
    summary = model_step("summarize", ticket)
    label = model_step("classify", ticket)
    return {"summary": summary, "label": label}

print(workflow("My invoice for October shows the wrong amount."))
```

```text title="Output (Python 3.14.8)"
{'summary': 'My invoice for Octob...', 'label': 'billing'}
```

## Predict the output

### Model tiering

Level 2.

```python
price = {"strong": 15, "mid": 3, "small": 1}
steps = ["strong", "mid", "mid", "small", "strong"]
tiered = sum(price[s] for s in steps)
print(tiered, price["strong"] * len(steps))
```

1. 37 75
2. 75 75
3. 35 75
4. 37 37

**Answer:** option 1.

```text title="Output (Python 3.14.8)"
37 75
```

**Why:** Strong for plan and review (15 + 15), mid twice (6), small once (1): 37 against 75 for all-strong.

## Check your understanding

Level 1.

**Q:** What is the difference between an agent and a workflow?

**A:** In a workflow your code decides the sequence of steps. In an agent the model decides the next step at runtime, in a loop, based on tool results.

**Q:** Why does "the harness beats the model" matter in practice?

**A:** Because most failures come from missing context, vague tools, or unenforced rules. Fixing those is cheaper and more reliable than switching models. Hence the shorthand: agent = model + harness.

**Q:** What separates agentic engineering from vibe coding?

**A:** Not the share of code the agent writes. In agentic engineering you design the system, define success with checks such as tests and evals, enforce rules in the harness, and measure cost and quality.

**Q:** What is the backend ancestor of a hook?

**A:** Middleware: guards and interceptors that run before and after a request. Hooks run before and after tool calls and session events.