The AI Agent Trends Engineers Should Actually Care About

I spent two days at AI Native DevCon London 2026, but the useful takeaway is bigger than the conference itself.

The useful part was the pattern that kept showing up across the talks. The AI agent trends worth paying attention to are the systems around the model: skills, context, harnesses, tools, security, evals, and team habits.

The ideas I am taking forward:

• Treat skills like code: version them, review them, test them, and retire them.
• Put reliability in the harness: context, tools, feedback loops, and checks.
• Make context owned and inspectable, not scattered across meetings and notes.
• Design for agents as real users of your logs, APIs, CLIs, CI, and browser surfaces.
• Give autonomous agents real security boundaries.
• Move review upstream, before the agent generates a large diff.

That was the shape of the conference for me. We are past the point where “the model can write code” is the interesting observation. The work now is making the whole system around the model dependable enough to trust.

Skills are becoming software dependencies

Guy Podjarny’s keynote, “Skills Are the New Code”, gave the event its clearest frame. A skill is not a nicer prompt. It is a production artifact that changes how an agent behaves.

That means the boring disciplines matter again:

• static analysis
• evals
• security testing
• dependency management
• observability

The security examples made this feel less theoretical. The risks were not vague “AI safety” risks. They were concrete software risks: malicious skills, skills with no safety boundaries, and skills that leak tokens to logs.

That changes how I think about skill files. If a skill can steer an agent into editing code, calling tools, or touching secrets, then it deserves the same treatment as code. Version it. Review it. Give it an owner. Delete it when it is stale.

Kevin Groetzinger made the maintenance side explicit. Skills need trigger phrases, ownership, and a path to retirement. Otherwise the team ends up with skill sprawl: a drawer full of clever instructions that nobody trusts enough to use or delete.

Macey Baker and Baruch Sadogursky had the most useful breakdown of the day: rules, skills, scripts, hooks, and evals. That is the decomposition I want to use more. Rules constrain. Skills carry judgment. Scripts do deterministic work. Hooks connect the system. Evals tell you whether the whole thing still behaves.

That is a better shape than one huge prompt trying to be policy, memory, workflow, and test suite at the same time.

Reliability is moving into the harness

Ryan Lopopolo’s harness engineering talk connected a lot of the conference for me. The harness is the deterministic software around the probabilistic model: the context you provide, the tools you expose, the autonomy you allow, the feedback loop, and the verification after the work is done.

OpenAI’s write-up on harness engineering uses the same framing for Codex. The useful question is whether the harness helps the agent recover when it is wrong.

That is the reliability lever I care about.

If a test fails, does that failure feed back into the next run? If the agent used the wrong file, does the context packet improve? If it needed too much access, does the tool boundary get narrower? If it made the same mistake twice, does an eval catch it the third time?

A demo only has to work once. A harness has to learn from the misses.

Context engineering is becoming product work

Rob Sloan pushed harness thinking beyond code, which I found useful. Agents need more than source files and commands. They need product goals, design intent, constraints, acceptance criteria, and decisions.

Most teams already have that context. The problem is where it lives.

It is in meeting notes, Slack threads, ticket comments, private docs, and the heads of people who have been around long enough to know why something is weird. A human can fill in those gaps from memory. An agent will act on whatever is actually present.

That makes context a product surface. It needs an owner. It needs review. It needs provenance. It needs to be easy to inspect.

Lamis from Anthropic described memory in a way that matched this: markdown, search, versioning, permissions, and human review. The phrase that stuck with me was filesystem-as-memory. Not because it sounds sophisticated. Because it does not. It is the kind of thing engineers can actually maintain.

The “dreaming” idea was the interesting layer on top. An out-of-band process reviews past transcripts, spots patterns, and proposes memory updates for a human to approve. That is the right level of automation for shared memory: let the agent notice the pattern, but keep the update visible and reviewed.

Agent experience is becoming developer experience

Dana Lawson’s Netlify talk was my favourite because it was painfully practical. Netlify was built around a human loop. Then agents started using it and exposed the weak spots.

Humans skim logs. Agents retry.

Humans infer intent from a dashboard. Agents need structured state.

Humans carry tribal knowledge. Agents need blueprints, recipes, and decision records.

That is Agent Experience, or AX. I like the term because it points at real interfaces: logs, APIs, CLIs, CI output, deploy flows, docs, errors, rollbacks. All the places where a human can improvise but an agent cannot.

The useful twist is that improving AX also improves developer experience. Machine-readable build errors help agents, and they make dashboards clearer. Intent-level capabilities help agents, and they make APIs less awkward for people.

Sandboxing is becoming part of the product

The same theme showed up in Oleg Selajev’s Docker talk from the security side: prompts are not security boundaries.

Once an agent can run commands, install packages, edit files, call tools, and start containers, the useful question is not only “do I trust the model?” It is “where is this agent allowed to act?”

That is why the Docker Sandboxes example matters. Docker describes Sandboxes as isolated microVMs for AI coding agents. Each sandbox gets its own Docker daemon, filesystem, and network, so the agent can build containers, install packages, and modify files without touching the host system.

That changes the product surface. The sandbox is no longer an implementation detail. It is where you decide what files are mounted, what network access is allowed, what credentials are available, and what policies apply across every developer’s machine.

A permission prompt is not the same thing as a boundary. If the agent can read your home directory, reach the network, and see secrets, then a prompt has already lost too much ground. The safer shape is to give the agent real autonomy inside a smaller world.

That is the part I want to carry forward. Agent speed is useful, but speed without boundaries just moves mistakes faster.

Review is moving before the diff

Hannah Foxwell’s talk made the team impact feel concrete. If agents make implementation faster, the bottleneck moves upstream.

Product clarity matters more. Spec quality matters more. Release safety matters more. Operations matter more. A manual review step that used to be annoying can become the place everything queues up.

The review point stayed with me. Reviewing thousands of lines of generated code is miserable. The better review target is earlier: the goal, the constraints, the acceptance criteria, and the shape of the solution.

That changes what senior engineering work looks like. Less waiting until the end to bless a diff. More shaping the work before the agent starts producing it.

Robert Overweg’s “one brain” talk connected to the same problem. Teams need a shared, inspectable knowledge surface with provenance and review. People and agents should draw from the same source instead of each building their own private pile of notes.

This maps directly to a problem I keep seeing: context loss between meetings, docs, tickets, transcripts, and skills. If every person and every agent carries a different version of the truth, agent speed just spreads confusion faster.

Browser surfaces are becoming agent surfaces

The browser version of the same idea is WebMCP.

Chrome’s WebMCP docs describe it as a proposed web standard for exposing structured tools to AI agents. Instead of asking an agent to look at screenshots, scrape the DOM, or guess what a button means, a page can declare the actions it supports.

That is the interesting shift. Browser automation today often means imitation: move the mouse, click the button, read pixels, infer state. WebMCP points at a different model. The site exposes tools, input schemas, outputs, and page state. The agent calls those tools through the browser.

For engineers, that makes the web part of the agent interface. A docs site might expose search and page lookup. An admin dashboard might expose filter, inspect, and approve actions. A deploy UI might expose diagnostics. A support tool might expose the exact form flow instead of hoping an agent understands the visual layout.

The tooling around it matters too. The GoogleChromeLabs webmcp-tools repo includes an inspector extension and eval tooling, which is a good signal. This should be testable, not just a new annotation trick.

The Chrome docs are clear that WebMCP is still a proposed standard and under active discussion. That is fine. The direction matters now: agent-facing browser surfaces should have structured actions, permissions, typed results, and inspectable state.

It also connects back to AX. If agents are going to use the products we build, the browser cannot only be a human visual surface. It needs to become a capability surface too.

What I am changing

The conference did not leave me thinking “use agents more”. It left me thinking our agent systems need more engineering around them.

For me, that means:

• Treat skills as production artifacts, not docs with ambition.
• Add small eval suites next to the skills we rely on.
• Make context packets explicit: goal, constraints, decisions, acceptance criteria, and owner.
• Design logs, APIs, CLIs, CI output, and browser surfaces for agents as real users.
• Sandbox agent work by default, with filesystem, network, credential, and audit boundaries.
• Look for places where structured browser tools would be better than asking an agent to imitate a person clicking around.
• Review the spec before the agent creates the diff.
• Move team knowledge into one shared, inspectable place.

The biggest immediate gap is evals. A small suite per skill would give us a way to change context with confidence instead of vibes.

The hard part is not proving that an agent can do useful work once. It is building enough taste, context, and discipline around it that the work can be trusted again tomorrow.