What is actually new in agent vocabulary
I have spent the last year reading AI agent announcements, talking to teams who shipped them, and getting buried in a stream of new terms. Half of them describe patterns I already use under different names. The other half describe patterns I should be using but had not named yet. Cassidy Williams wrote a GitHub Blog post on September 2, 2026 that laid out nine of these terms in one place. I read it, then talked through each one with a small group of engineers, and what follows is what I actually think is useful, what is just renamed old work, and what to do about it.
The agent boom brought a fresh wave of labels because the teams shipping agent features every two weeks needed shorthand. The trouble is what happens when the shorthand escapes the team. Job listings, conference talks, and product pages get dressed up in language that makes new readers feel behind. The lens I apply is straightforward: does this concept save me time, or does it rename something I already know. Below are the terms I think matter, in roughly the order they show up in an actual build.
Loop engineering
Loop engineering is what you get when you stop running agents by hand and start scheduling them. Picture the everyday chore of triaging new GitHub issues. Without a loop, you log in every morning, paste a list of issues into a chat box, ask for summaries, ask for fix suggestions, and then go fix them yourself. With a loop, the fetch, prompt, validation, and notification steps run on a schedule, and you only get pinged when something gets stuck. That is the whole shape of it. People compare it to cron, and they are not wrong. The difference is the validation step, which is the part cron never had.
A loop that runs well tends to share a few ingredients.
- Schedules take the place of ad-hoc prompts, which is what makes it a loop and not a habit.
- Validation gates keep bad answers from reaching users, since you cannot watch every run.
- Escalation rules protect your sleep, so a routine task does not page you at 3am.
- Observability matters more than usual because agent behavior drifts in ways cron jobs never did.
- Skills and checkpoints turn one team’s loop into a template another team can reuse.
Ralph loops
A Ralph loop is the simplest version of a loop, and usually the most expensive. You hand the agent a spec, often lifted straight from a product requirements document, and let it keep trying until the work looks done. The agent plans, acts, reads its own output, and starts over. In practice every cycle burns more tokens than the last one, and a large spec with loose validation can empty a monthly API budget in an afternoon. Loop engineering tries to package this pattern so it stops being a money pit. The primitives are familiar: skills, observability, validation, routing, checkpoints. The point is that none of them are optional.
- Best when the spec divides cleanly into a plan-act-check rhythm.
- Worst when the validation rule is fuzzy, because the agent will keep cycling until it looks acceptable.
- Cost is the constraint that decides whether this works at all.
- Checkpoints save work the agent already finished, which is the difference between cheap and ruinous.
- Routing hands different task shapes to different agent configs, instead of asking one model to be good at everything.
Squads and fleets
Loops describe when an agent runs. Squads and fleets describe who is running. A squad is a small team of agents with distinct jobs, usually modeled on a human engineering team: planner, reviewer, implementer, tester, reviewer again. A fleet is more about parallelism, many agents doing similar work at once. The two compose: a squad inside a fleet can fan out across independent tasks, or a squad can take turns in sequence so the reviewer gets to look at work before it leaves the building.
The trade is specialization versus coordination overhead.
- Squads shine when the role boundaries stay sharp and rarely overlap.
- Fleets are useful for embarrassingly parallel work, like generating test cases.
- Sequential squads cut down on wasted compute by checking plans before implementation.
- Specialization lets you tune one agent without destabilizing the others.
- The cost is coordination, which means shared context and explicit handoffs.
Harness engineering
The harness is the part nobody puts on a slide. It is the auth layer, the permission model, the tool calling contract, the retry policy, the rate limiter, the logging. If you skip it, your agent looks magical in a demo and flaky the first week it faces real users. A solid harness spells out what the agent can see, what it can do, and what happens when something goes wrong. That is the entire difference between a demo and a service.
- Keep tool access tight, so the agent cannot reach for things it should not.
- Log every tool call so debugging drift does not become a guessing game.
- Set rate limits and timeouts to keep one runaway run from clearing your budget.
- Version prompts and harness config the way you version code, so changes are reviewable.
- Never grant production database write access without a human review step in the path.
Hill climbing and the rest
The other terms in the GitHub post are shorter to summarize. Hill climbing is the rebranding of an old optimization technique. You score the agent’s output, compare it to a target, then nudge the prompt or approach and try again. It is the pattern behind most “self-improving agent” demos on social media, and it works when the scoring function is honest and the iteration loop is fast. Forward deployed engineers, often shortened to FDEs, is a Palantir term that has migrated into AI circles. It describes engineers who sit with the customer and ship AI features into the customer’s actual workflow, rather than handing off a generic platform. Closed models are the API-only proprietary systems where you never see the weights or the training data. Open weights publish the weights so you can run the model yourself, but the training recipe and data usually stay private. Open source goes the last mile, with training code, data, and weights all released for inspection and modification.
- Hill climbing wants a clear scoring function and a tight iteration loop, otherwise you are just guessing.
- FDEs cost more up front but skip months of misaligned requirements gathering.
- Closed models are easy to adopt but you are buying into one vendor’s roadmap and pricing.
- Open weights give you privacy and control, paid for in infrastructure you have to run.
- Open source is the most flexible, and the most expensive in engineering time.
Trade-offs
Most of this vocabulary is fine inside a small team. It is worse in public, because it makes outsiders feel they have to learn a fresh dictionary to keep up. If you are hiring, ask candidates what they have built and what broke. If you are a candidate, talk about your loops and your validation rules instead of brand names. And if you are evaluating an agent platform, the questions that matter are plumbing questions: what does the harness look like, what does observability cost, what happens when the agent fails at 2am, and what is the runbook for rolling back a bad checkpoint. None of those answers live in the new vocabulary.
What I would tell past me
Start with one loop that replaces a daily manual task. Watch the token bill. Add observability before you add a second agent. That is the whole game. Do not memorize the vocabulary. Memorize the patterns, then call them whatever makes sense to your team. The names are shorthand for the builders, not a syllabus for everyone else.