Agentic Everything: Are We Building the Right Abstractions?
A skeptic's take on the AI agent hype cycle. Towers of scaffolding, a tiny kernel of value, and the abstractions that actually survive production.
Maya asked her agent to book a meeting. The agent confirmed the time, checked the attendee's calendar, drafted a crisp agenda, and sent the invite. Everything looked polished. The only problem: it booked the previous Tuesday. A date that had already passed by six days.
The failure was aesthetically perfect. Confident. Polished. Completely wrong. The agent did everything its framework defined as correct. It just didn't understand time.
That's not a bug. It's a fundamental property of the abstraction we're building on.
The Colleague Mental Model Will Burn You
Most of us — myself included at first — model LLM agents as smart colleagues you can delegate to. You'd tell a colleague "book this for Tuesday" and they'd check: "Do you mean this coming Tuesday or next?" They'd flag ambiguity. They'd push back. That mental model is every agent framework demo's foundation, and it's wrong in a way that bites every time.
An LLM agent is a stateless text predictor with tools attached. Input: whatever fits in the context window. Output: the most statistically plausible token sequence, possibly wrapping a tool call. Between calls, nothing persists. There are no goals — only probability distributions over next tokens conditioned on the prompt.
Maya's agent didn't "think" it was booking the right date. It generated the most statistically plausible sequence given its input. That sequence happened to include a past date. When the colleague mental model meets stateless token prediction, you get failures that look and feel like competent work — until you check the details.
The colleague mental model is the root cause of most agent failures. Design for a stateless text predictor with tools, not for a smart teammate.
Why Most Agent Frameworks Are Solving Yesterday's Problem
The first wave of agent frameworks made GPT-4's capabilities accessible: chain-of-thought, tool use, multi-step planning. That was genuinely valuable. But the hard part was never capability. Maya's agent had capability — it used tools correctly, confirmed before acting, formatted its output impeccably. What it lacked was reliability, observability, and controllability.
Frameworks solve for capability because capability is what demos well. Reliability means trust without verification. Observability means replaying why a decision was made. Controllability means intercepting before damage. Most frameworks treat these as afterthoughts — installable plugins, not architectural primitives.
The results are predictable: confident failures at the edges of the training distribution, without signaling uncertainty. That last part is the dangerous bit.
| Failure Mode | Why It Happens |
|---|---|
| Ambiguous instructions | Colleague would ask — agent generates plausible guess |
| Time-sensitive context | Calendar problem — no grounding in "now" |
| Cross-session state | Stateless between calls, no persistence primitive |
| Confident wrongness | No uncertainty signal — output looks clean regardless |
The Durable Kernel Is Small
After debugging Maya's calendar incident, I stripped every agent I maintain down to a kernel of three things: a memory store, tool contracts, and guardrails. Everything else — planning loops, reasoning chains, meta-prompts — sits on top of that kernel, not inside it.
The memory store holds what survives between calls — not the whole conversation, but decisions, references, and state that the agent needs to persist. Tool contracts define not just what a tool does, but what happens when it fails: timeout, retry budget, fallback output. Guardrails are not suggestions — they are hard boundaries enforced at the infrastructure level, not the prompt level.
This kernel is small enough to reason about, test, and trust. Everything above it — the agent framework, the orchestration layer, the UI — becomes replaceable. That's the point. When a new framework ships next month with better planning, you swap the top layer without rebuilding the kernel.
My listing evaluation pipeline is the most useful agentic system I've built on this kernel. It ingests records on a schedule, filters against configurable qualification gates (role fit, location constraints, application friction), evaluates each passing record against a quality rubric, and surfaces the top matches in a periodic digest. Every step uses a different tool from the kernel's tool contract layer — the schedule fires a trigger, the filter is a deterministic rule node, the evaluator calls an LLM with structured output, the digest is a template — and each tool has explicit failure handling. When the LLM returns malformed JSON, the kernel doesn't retry indefinitely. It logs the error, moves on, and the digest includes "3 records skipped due to evaluation error." Human review catches the gap.
The orchestration runs in n8n, not an agent framework. This is not accidental. n8n is a workflow engine — a series of nodes that each do one thing, with explicit branching and defined error states at every step. I can open any past run and see exactly what happened at each node. If a step fails, the workflow stops and I get an alert. If I need to change a filter criterion, I change one node. That's observability, controllability, and maintainability — the three things agent frameworks consistently underdeliver on. The "agent" behavior emerges from the workflow design, not from framework magic. I want to understand exactly why it did what it did.
| Component | Tool Used | Failure Behavior |
|---|---|---|
| Schedule trigger | Cron node | Missed window → next run catches up |
| Qualification filter | Rule node (deterministic) | Bad rule → logs which record failed |
| Quality evaluation | LLM node (structured output) | Malformed JSON → skip, flag for review |
| Digest assembly | Template node | Empty set → sends "no matches" instead of breaking |
| Human approval | Webhook pause | Timeout → defers to next run, alerts owner |
The kernel didn't make the pipeline smart. It made the pipeline honest. When the evaluator fails, you know why. When a record gets skipped, you can find it. When the digest is empty because nothing matched, nobody wastes time reviewing a blank screen. That's the value of the small kernel: not intelligence, but truth in advertising from every component.
The Architecture Follows the Answer
Before Maya builds any agentic system now, she answers one question first: what happens when this is wrong?
- Catastrophic — wrong data written, wrong person emailed, money moved → human review before the action executes
- Annoying but recoverable — wrong file created, wrong API call that can be retried → automate with hard retry limits and rollback
- Unnoticeable — imperfect summary, slightly off classification → fully automate and move on
Maya's calendar agent sat in "annoying but recoverable." The fix wasn't a new framework or a smarter model. She added 60 seconds of wait time after the booking, then sent herself a confirmation with the booked date for review before the invite went out. That's the production fix. The aesthetically perfect failure became an adequate system that hasn't misbehaved since.
The question you answer before you build is the difference between a system that runs reliably and one that books meetings in the past.
The agents that survive production aren't the smartest ones. They're the ones with honest abstractions — a small trustworthy kernel and replaceable scaffolding around it.
Stay with us · poll
Are We Building the Right Abstractions for AI Agents?
What do you think is the biggest challenge in designing effective AI agent frameworks today?
No account needed — pick a take, then keep reading. We rotate these prompts so each piece feels like a conversation, not a clone.
