Mert

When I first started using coding agents seriously, I made a familiar mistake.

I treated the model as the main thing.

I wrote better prompts. Then longer ones. Then, more carefully structured ones.

Sometimes it worked beautifully.

Sometimes it drifted.

Same repo. Same goal. Different result.

That inconsistency bothered me, because it revealed something deeper:

The bottleneck was not raw intelligence.

It was context.

In AI Is Not Replacing You. It’s Reshaping How You Think, I wrote about how AI shifts the bottleneck upward. When generation becomes cheap, the differentiator becomes judgment, constraints, and systems thinking.

That same pattern shows up in agentic engineering.

The real leverage does not come from asking a model to do more.

It comes from designing a better system around the model.

The Mistake I Kept Making

Early on, I was treating the agent like a very smart freelancer with amnesia.

I would drop it into a task, explain the problem, and expect one well-written instruction block to carry the entire interaction.

Sometimes it did.

But as soon as the work became real, things broke down.

Design fidelity mattered.

SEO mattered.

Content structure mattered.

Localisation mattered.

Existing conventions mattered.

Small decisions from earlier in the build mattered.

One prompt was never going to carry all of that.

That’s when it clicked:

Agentic engineering is not prompting.

It’s environment design.

On a recent workflow, I wasn’t asking an agent to “build a website.”

I was asking it to:

• work inside a multilingual Astro codebase
• preserve structured SEO
• keep markdown content editable
• support Arabic RTL layouts
• respect project-specific rules already established
• generate UI directions using Stitch
• interact with external tools through MCP integrations

That’s not a prompt problem.

That’s a context problem.

And context has to be layered.

If the model is the engine, skills are the practised moves, MCPs are the ports to the outside world, and AGENTS.md is the field manual for the project.

Once I started seeing the stack this way, everything became more stable.

Skills Are Reusable Judgment

The clearest explanations of skills come from:

• Anthropic’s Agent Skills Overview
• Strapi: What Are Agent Skills
• Agent Skills Format
• skills.sh (a curated and security-conscious skill registry)

The idea is simple:

A skill packages repeatable expertise into something an agent can reuse.

That matters because prompts are temporary.

Skills are accumulated judgment.

Instead of re-explaining how to:

• audit SEO
• structure content
• apply system constraints

…you encode it once.

Now every task starts from a higher baseline.

In practice, skills do three things:

• reduce repetition
• reduce drift
• make quality portable

That last one is the real shift.

Without skills, success depends on remembering the right phrasing at the right time.

With skills, you turn one-off cleverness into infrastructure.

That’s leverage.

MCPs Give Agents Reach

If skills shape how an agent thinks, MCPs shape what it can do.

The Model Context Protocol is an open standard that connects models to external systems.

Models know patterns.

MCPs let them touch reality.

That reality includes:

• repositories
• APIs
• documentation
• browsers
• design tools like Stitch
• databases
• internal tools

Without MCPs, an agent is reasoning in isolation.

With MCPs, it can:

• observe
• verify
• act

That’s the difference between generating suggestions and executing work.

AGENTS.md Gives Agents Memory

The part most teams underestimate is memory.

That’s where AGENTS.md comes in.

The simplest way to think about it:

It’s a README for agents.

But unlike a typical README, it captures the operational reality of a project:

• how the codebase behaves
• Which commands are safe
• what constraints must be respected
• what has already been learned

In one of my workflows, this included things like:

• why Tailwind must stay locally compiled
• why English routes remain unprefixed
• how RTL must be handled
• what business details must remain consistent

Without this, the agent rediscovers the project every time.

With it, the agent starts from context.

This ties back to something I wrote in Why I Write:

Writing forces clarity.

Good documentation does the same thing for systems.

It turns implicit knowledge into something reusable.

The Agent Is Not the System

This is the part that matters most.

People talk about agentic engineering as if the intelligence lives entirely inside the agent.

It doesn’t.

The agent is just one layer.

What makes the system reliable is the composition:

• the human provides intent and judgment
• skills provide reusable expertise
• MCPs provide access to reality
• AGENTS.md provides memory
• the agent executes within that structure

That’s the system.

Recently, I watched a talk by Jacob Bank (ex-Google, founder of Relay.app) that reinforced this perspective:

A few ideas stood out:

• AI is not your intern
• managing people becomes less central than designing systems
• build one simple agent at a time
• fire agents that don’t deliver
• clarity of intent is everything
• your personality becomes the differentiator

That framing aligns closely with what I’ve experienced.

The leverage doesn’t come from one powerful agent.

It comes from how well the system around it is designed.

That’s why I don’t think the future belongs to people who are just good at prompting.

It belongs to people who can design systems of context.

People who can decide:

• what should be reusable
• what should be connected
• what should be constrained
• what should remain human

In Building Better: Looking Back on 2025, I wrote about building better systems around my life and work.

This is the same instinct.

The goal isn’t to layer AI onto existing habits.

The goal is to redesign the workflow so intelligence has somewhere useful to go.

Agentic engineering is not the art of finding one perfect prompt.

It’s the discipline of building context architecture that makes good work more likely.

That’s where the leverage is.

That’s where the quality comes from.

And that’s where the real craft of this era is being built.

What I’m Exploring Next

This piece is part of a broader exploration into agentic systems.

Next, I’ll be diving deeper into:

• Model Context Protocol (MCP) and how it actually works in practice
• Designing skill libraries for real production workflows
• How to structure agent-first systems in real applications

Further Reading

• What Are Agent Skills and How To Use Them
• Anthropic: Agent Skills Overview
• Model Context Protocol: Introduction
• AGENTS.md
• What Are Skills?
• skills.sh

This will be a short post.

I toyed with plenty of AI and types of AI. LLM, Reinforcement Learning, Alphazero, from scratch or using large framework, etc

There are a few major key points :

• If an AI can cheat, it will. It’s a well known behavior since the infancy of AI. It will maximize reward by any means.
• If there is a bug to exploit, it will find it.
• Garbage-in, Garbage-out, is greatly underestimated. The quality of an AI is all about the quality of data. Not only for LLM but also for RL.

I’m a DBA, my job is data. But even then, when it comes to AI it’s not a fun job: Data quality is difficult to evaluate and this evaluation is time consuming.

Sanity checklist

If you’re planning to work on AI, here are some things to remember:

• You’ll never have enough compute power (yes, i repeat it again).
• You’ll never have enough memory.
• Make everything resumable. Do not wait the end of a 12h long processing to save outgoing results. Save them asap. (learned the hard way and still manage to forget from time to time)
• Save everything, do not be cheap on disk space.
• The more compute & memory you have, the more you’ll use it. Scaling just works.
• If you’re doing inference and you can send concurrent queries, use vLLM. We’re talking about 100tok/s vs 5000tok/s here. It’s massive. Don’t hesitate to push 64, 128 concurrent queries. It scales until you run out of VRAM.
• I’ve tested all kinds of platforms. Apple Silicon is amazing and it works. But nothing can beat nVidia yet. The main advantage of Apple Silicon is its competitive price. (I never thought i would ever say that but here we are…)

AI Research

Amateur AI research is a bit like Amateur Astronomy. There are plenty of amateur research to be done, many unexplored spaces, … But it’s expensive to do and whatever result you get will have 0 visibility until someone finds out your work and make a thesis out of it.

And even then, a thesis can stay ignored for months, or years, until some dude in a hyperscaler company stumbles upon it and use it.

Just do whatever pleases you, or whatever you need. Everything else is white noise in an ocean of AI Slop. But i get it, it sure is frustrating when you wake up one morning and find thousands of youtube influencers and AI generated article talking about some “revolution” that you already knew about a year ago.

Most automation tools feel impressive right up until you have to trust them.

It is easy to demo a scheduler.

It is much harder to build one that survives real life:

• expired tokens
• flaky platform APIs
• posts that need review
• queues that drift out of sync
• failures that happen while you are asleep

That gap changed how I think about automation.

I have been building a project called PostPunk, and I thought the hard part would be generating content and wiring platform APIs together. That turned out to be the easy part.

The real work was operational trust.

A useful scheduler needs a few things that demos usually skip:

1. Approval states matter

Not every post should go straight from draft to published.

Some posts are written by you and are ready immediately. Some are AI-assisted and need a second look. If your system does not distinguish that clearly, you end up either babysitting everything or accidentally posting junk.

So I ended up treating post states as part of the core workflow, not just metadata:

• draft
• approved
• posted
• failed

That sounds simple, but it changes everything.

2. Failure is not an edge case

In scheduling systems, failure is normal.

A platform token expires.
An API rate-limits you.
A platform changes a field name.
An account is misconfigured.
A browser fallback stops matching the UI.

If the whole system falls apart the moment one target fails, you do not have automation. You have a fragile demo.

So the system needs:

• retries
• visible failure states
• alerts
• manual assist when automation is not trustworthy

3. Automatic is not the same as unattended

A lot of posting tools sell the dream of full autopilot. In practice, a better model is often:

• automate what is stable
• assist where platforms are hostile
• keep the queue and schedule as the source of truth

That still saves a huge amount of time, and more importantly, it is honest.

4. Scheduling is really an operations problem

The UI part is not enough.

You also need:

• a worker that checks for due posts
• logs
• retry logic
• success and failure alerts
• a clear what is due today view

Without those, the schedule is just decorative.

What I learned

The hardest part of automation is not getting software to do something once.

It is getting it to behave predictably enough that you stop worrying about it.

That is the part I care about now.

If you are building internal tools, creator tools, or any kind of scheduler, reliability is the actual feature. Everything else is packaging.

PostPunk is still a project I am actively working on, but building it has made me much less interested in shiny automation promises and much more interested in boring operational trust.

Most commentators are either a has-been or someone who never made the team. There is great content, thats not the argument here.

It’s not hate. That’s just true. Sports. Music. Business. Tech. The people in the booth talking about the game are not the ones playing it.

If you’re a developer right now spending more time consuming content about building than actually building, you might be sitting in the booth and not realizing it.

This is the tap on the shoulder.

The content trap looks exactly like productivity.

You know the loop.

Open the laptop. Today’s the day. But first, check that Reddit thread about the new framework. Then 20 minutes of a podcast where two guys debate which LLM is better. Then a tutorial you skim, bookmark, and never come back to.

Two hours later your editor is still empty.

But you feel like you did something.

That’s the trap. Your brain got fed technical language and new ideas so it gave you the same reward it would’ve if you actually built something.

You didn’t.

And that gap compounds. Quietly. Over weeks. Over months.

I’m not calling you out. I’ve been in that loop. I’m just telling you what it looks like from the outside.

Nobody buys a ticket to hear the commentators.

I’m from Ottawa, Ontario, Canada. Grew up on hockey.

And every fan knows this instinctively. You don’t go to the game for the broadcast. You go to watch who’s on the ice.

Most dev podcasts. Most AI Twitter threads. Most “10 tools you need” posts. That’s commentary. And commentary has value. But it’s not the game.

If your goal is to build, to ship, to actually play, you need to get on the ice.

Touch the puck. Put your name on a repo. Push something live that could break.

I’m on the ice right now. Player-coach. Still getting hit. Still learning every shift. But the view from inside the game is nothing like the view from the booth.

Talk to devs who are building. That’s happening here on Dev. Get in their comments, ask questions, go to Hackathons, make friends. Watch what they ship. Not what they say.

That’s your peer group. Not the podcasters.

The devs pulling ahead aren’t smarter. They just closed the tab sooner.

Go look at their GitHub profiles. The ones getting hired. Getting funded. Getting noticed.

Their repos aren’t clean. Their READMEs are half done. Their commit messages are gibberish.

That’s what building actually looks like.

They didn’t wait until they felt ready. They started before the tutorial was finished. They asked Grok stuff mid-build. They shipped ugly and fixed it in public.

The gap between them and the dev who “almost started that project” isn’t talent.

It’s the moment they closed the browser and opened the editor.

Backboard shipped major updates last week, looking back at the original, I can’t believe we’re the same company. 🤯

You’re closer to the bleeding edge than you think.

If you’re reading this, you are closer to the frontier of technology than almost everyone on the planet.

The non-technical world is watching AI happen to them. They don’t know what an API is. They don’t know what a context window does. They’re not dumb. They’re just not in this world.

They need people who can build things that work and explain why they matter.

That’s you.

But only if you build.

The risk right now is you stay in the consumption loop long enough that someone who knows less than you but ships faster ends up defining what gets built.

Not because they’re better. Because they started.

The fastest way to learn is to build something that breaks.

Not a course. Not a cert. A project that breaks in public and forces you to fix it.

When you ship something you hit real problems. Not textbook problems. Real dependency conflicts. Real “why is my state disappearing between sessions” moments. Real user feedback that makes you rethink everything.

That’s where learning actually lives.

Every senior dev you look up to got there the same way. Building. Breaking. Fixing. Doing it again while people watched.

If you want to skip the part where you spend two weeks wiring up memory and state before you even touch the thing you want to build, Backboard handles that. Free state for life on signup. Not the point of this article. But it kills one of the quietest excuses I hear from devs who don’t ship: “I’m still setting up infrastructure.”

You don’t need permission. You need a deadline and a publish button.

Pick one thing. One idea you’ve been sitting on.

Give yourself 48 hours. Ship it.

Ugly is fine. Three views is fine. What matters is you broke the loop.

After my last article went viral on here, the DMs I got weren’t asking for resources or reading lists. They were all some version of the same thing:

“I needed someone to tell me to stop overthinking it.”

So here it is again.

Stop overthinking it. Close the tabs. Open your editor. Build the thing.

I’ll see you on the ice.

PS: My one book to recommend that aligns with this post would be Extreme Ownership.

A new paper from UC Berkeley, UCL, and Shanghai Jiao Tong University proposes a compelling vision: the Agentic Web, an internet where AI agents — not humans — are the primary operators. Users state goals in natural language; agents plan, coordinate, and execute across services autonomously.

The paper is thorough. It maps three dimensions of this new web (intelligence, interaction, economy), catalogs open challenges (trust, interoperability, reward design, catastrophic forgetting), and surveys the protocol landscape (MCP, A2A). What it doesn’t do is prescribe how to build the missing infrastructure.

That’s where things get interesting for us. Because the requirements the paper identifies — modular capabilities, competitive markets, decentralized trust, cross-platform portability, quantified fitness evaluation — are not hypothetical needs. They’re the exact mechanisms Rotifer Protocol has been building since v0.1.

The Paper’s Requirements vs. Existing Mechanisms

The Agentic Web paper articulates five structural requirements for a functioning agent ecosystem. Here’s how each maps to protocol-level mechanisms that already exist or are formally specified:

1. Modular, Transferable Capabilities

The paper says: Agents need composable capability units that can be shared and reused across the network.

What exists: The Gene model — atomic logic units satisfying three axioms (functional cohesion, interface self-sufficiency, independent evaluability). Genes carry their own I/O schema (Phenotype), are content-addressed by hash, and transfer between agents via Horizontal Logic Transfer.

2. Competitive Markets for Agent Capabilities

The paper says: “Agent Attention Economy” — services will compete for agent invocations the way websites compete for human clicks. Agent call frequency becomes the new traffic metric.

What exists: The Arena — a continuous ranking system where genes compete on standardized benchmarks. Fitness F(g) is a multiplicative function:

F(g) = (S_r × log(1 + C_util) × (1 + R_rob)) / (L × R_cost)

Agents prefer top-ranked genes. Low-fitness genes retire. The selection pressure is quantified, reproducible, and resistant to gaming through multidimensional scoring and sliding-window evaluation.

3. Decentralized Trust Infrastructure

The paper says: Agents operating autonomously need trust mechanisms that don’t depend on human verification at every step.

What exists: Two complementary systems:

• V(g) — a security score computed from static analysis (7 scanner rules, S-01 through S-07) that gates Arena admission. No test suite = no entry.
• L4 Collective Immunity — a network-wide threat ledger with temporal decay, defense sharing, and consensus-verified writes. A vulnerability detected by one agent generates defense fingerprints that protect the entire network.

4. Cross-Platform Interoperability

The paper says: Agents and their capabilities need to work across heterogeneous environments — different clouds, different runtimes, different platforms.

What exists: The Rotifer IR — genes compile to WASM with custom sections carrying metadata, schemas, and verification proofs. Before execution in a new environment, a formal negotiation protocol checks compatibility:

negotiate(gene.irRequirements, binding.capabilities)
// → Compatible | PartiallyCompatible | Incompatible

Three Binding types (Local, Cloud, Web3) are already implemented. The abstraction eliminates “works on my machine” at the protocol level.

5. Reward Design That Resists Gaming

The paper says: Designing reward mechanisms that guide agent behavior without being exploited is an unsolved bottleneck.

What exists: F(g) uses a multiplicative model where any zero-valued dimension (security, reliability, coverage) zeros the entire score — you can’t compensate for a security hole with speed. Anti-gaming measures include Sybil detection, reputation discounting, sliding evaluation windows, and diversity-adjusted display ranking that penalizes monoculture.

What the Paper Covers That We Don’t

The Agentic Web paper is a full-spectrum vision document. It covers topics outside the scope of an evolution protocol:

• Search engine replacement — how agents will change information retrieval paradigms
• Labor market disruption — socioeconomic implications of agent automation
• Advertising model transformation — the shift from human attention to agent attention economics
• Recommendation systems for agents — how to surface relevant services to autonomous agents

These are important questions. They’re just not protocol-level questions. Rotifer focuses on the capability layer — how agent logic is created, evaluated, secured, and propagated — and leaves the application-layer questions to the teams building on top of the protocol.

What We Cover That the Paper Doesn’t

Conversely, several mechanisms in Rotifer address gaps the paper identifies as open challenges but doesn’t propose solutions for:

Independent Convergence

The most interesting aspect of this alignment isn’t that Rotifer answers the paper’s questions — it’s that the questions were asked independently. The Berkeley/UCL/SJTU team arrived at their requirements through survey methodology and multi-institution analysis. Rotifer arrived at its mechanisms through bio-inspired protocol design. Neither referenced the other.

When independent research paths converge on the same structural requirements, it’s a signal that those requirements are real — not artifacts of a particular framing.

The Agentic Web paper maps the territory. Evolution infrastructure builds the roads.

Try it: npm i -g @rotifer/playground · rotifer.dev · Docs · Paper