Theme: The Shift

Length: ~800 words

Hook: Contrarian — challenge the current approach

Everyone is building AI agents. Almost everyone is building them wrong.

Not wrong in the "it doesn't work" sense. Wrong in the "we're repeating the same mistake we've made in every technology shift" sense.

Here's the pattern:

1990s: Everyone built websites. Most were brochures with no function. The web became useful when we stopped thinking about "having a website" and started thinking about what the website did.

2000s: Everyone built mobile apps. Most were desktop experiences crammed onto a phone. Mobile became useful when we stopped porting and started designing for the medium.

2010s: Everyone built microservices. Most were distributed monoliths with extra steps. Microservices became useful when we stopped decomposing and started designing boundaries.

2020s: Everyone is building agents. Most are chatbots with extra tools bolted on.

The mistake is the same every time: we take an old paradigm, add the new buzzword, and ship it. We don't rethink the fundamentals.

Here's what we mean for agents:

We're building agents as if they're functions. Input comes in, output goes out. But agents aren't functions — they're autonomous actors. They perceive, decide, act, and learn. Treating them like stateless functions is why they fail in production.

We're wiring agents with boilerplate instead of declaring them. Every framework today requires 500+ lines of glue code to define a single multi-agent pipeline. We import 15 classes, wire them manually, and hope the types match at runtime. This is the equivalent of writing SQL queries as imperative code — it works, but it misses the point.

We're deploying agents without governance. An agent that can call tools, access data, and make decisions is an agent that can cause harm. Yet most teams deploy agents to production with no approval gates, no cost ceilings, no audit trails, and no policy enforcement. We'd never deploy a microservice without monitoring. Why are we deploying agents without governance?

We're treating agents as products instead of capabilities. "We built an AI agent!" is not a value proposition. What problem does it solve? Who does it help? What does it do that a simpler system couldn't? The suitability question — "should this even be an agent?" — is almost never asked.

We've been building agent systems for a while, and we've made every one of these mistakes. The pattern we've learned is:

  1. Start with the problem, not the agent. If a lookup table solves it, use a lookup table. Agents are for problems that require reasoning, context, and adaptation.
    1. Declare, don't wire. An agent's capabilities, tools, memory, and constraints should be declarative — not 500 lines of imperative glue code. This is why we need better abstractions (or, in our case, a language).
      1. Govern before you ship. Intake, evaluation, approval, monitoring. Every agent that touches real data needs these gates. Not as documents. As code.
        1. Audit everything. If you can't answer "why did the agent make this decision?" with evidence, you're not ready for production.
          1. Build for the medium. Agents aren't chatbots with tools. They're a new computing paradigm. Treat them that way.

            2. The teams that get this right will build agents that are trustworthy, governable, and genuinely useful. The teams that don't will build demos that break in production and erode trust in AI.

            We're at the beginning of the agentic era. The fundamentals matter more than the features.

            What patterns have you seen? What mistakes are teams making?