Horizontal Skills and Vertical Agents

Most teams now use AI to write code. Far fewer have managed to hand an agent a real, long-running piece of work and trust the result without watching every step. That gap – between a clever autocomplete and an agent you can actually delegate to – is where the interesting questions live.

For several months I have been building software with agents doing the bulk of the work: running autonomously for hours rather than minutes, covering not just whether the code compiles but whether it is well-architected, secure, and performant – while I stay where human judgment actually matters, setting direction, exercising taste, and signing off. The goal is blunt: give one person the coordinated reach of a small team. It is an ambitious target, and it runs straight into two hard limits that shape everything else.

Two limits every agent hits

The first is context. An agent’s working memory is finite, and – this is the uncomfortable part – its quality degrades as that memory fills. The more an agent has read (the design docs, the architecture, the prior reviews, the conversation so far) the worse its next decision tends to be. A single agent that accumulates everything it has seen over a long task gets quietly, steadily worse the longer it runs.

The second is rule-following. Ask one agent to honour architecture and security and test strategy and code quality and product intent all at once, and past a certain density of rules it reliably applies none of them well. This is not unique to machines – overload a human reviewer with twelve competing checklists and the same thing happens.

Both limits point at the same culprit: one agent trying to do everything and hold everything. That is the bottleneck. The rest of this is about removing it.

Stop making one agent good at everything

The fix is to stop trying to make one agent good at everything. Instead, split the judgment across many narrow agents, each looking at the whole project through a single lens. An architect agent reasons only about system shape, boundaries, and dependencies. A coder owns implementation craft and local quality. A security officer looks only at threats, data handling, and compliance. A requirements engineer keeps scope and intent honest. A process owner watches the workflow itself.

Each one is vertical because it cuts top to bottom through the entire codebase – but only along its own concern. On a given project you add or drop columns: a fintech system wants security and compliance front and centre; an ML system wants data-quality and evaluation. The roster is simply the set of concerns the project would staff specialists for if it could afford them.

The discipline is what makes it work. Each agent carries only the rules of its own lens, so it can actually follow them. Each runs in a fresh, isolated context every time it is invoked – it never inherits the clutter of the orchestrator’s conversation, which keeps both its memory small and its review independent. Each is read-only by default and returns a fixed, compact report. And critically, each agent escalates anything outside its lane rather than guessing past it. Narrow rules, clean context, a locked output – that is the whole recipe.

Skills run horizontally across the agents

If vertical agents are judgment, horizontal skills are the workflow – the reusable verbs that run across all the agents: plan a milestone, plan a feature, implement, review. A skill owns sequence, state, and orchestration; it carries no domain rules of its own. At each step that needs judgment, it fans the work out to the relevant agents in parallel, collects their verdicts, synthesizes one integrated result, and escalates genuine conflicts to the human – it never silently picks a side.

Picture the whole thing as a matrix. The vertical agents are the columns – slices of judgment that stand through the whole codebase. The horizontal skills are the rows – phases of work that sweep across every column.

That independence is the practical payoff: swap the skill set and the agents still work; swap the agent roster and the skills still work. The skills are transferable workflow IP you build once; the roster is the part you tailor per project. That is what turns “horizontal × vertical” from a slogan into an architecture you can actually reuse.

Plan the WHAT, defer the HOW, review all the way

A couple of principles keep the whole thing honest. In planning, decide the what before the how: a milestone names which features come next, a feature is a slice a human can actually experience, and only at the lowest level – the task – do you commit to implementation detail. And you commit that detail as late as you responsibly can, because a spec written too early describes a system that no longer exists by the time you build it.

In execution, the agents build autonomously, but review does not wait until the end. Every task is reviewed as it is written, then the whole feature is reviewed once it is assembled, with cheap mechanical checks – formatting, linting, the test suite – running underneath on every commit. The human’s touch-points are deliberately few: set the direction, converge on the rare thing that can only be judged by looking at it, and verify the finished deliverable before it ships. Everything in between runs without a babysitter – and because every step runs in fresh context with state written to disk rather than held in an agent’s head, a feature can run arbitrarily long without the slow quality-decay of that first limit.

The process improves itself

One more piece makes this durable. The workflow itself – the skills, the agent definitions, the rules – lives as versioned files, reviewed and rolled back like any other code. When a rule keeps getting missed during real work, that friction is captured as a tracked issue and turned into a better skill, a sharper agent, or a structural change that makes the mistake impossible.

The governing instinct is counter-intuitive: rule-load is a budget to be cut, not grown. The default response to friction is “which existing rule should have caught this?”, not “add another rule.” I did not design this on a whiteboard – it evolved over roughly five months on a real, long-running codebase, with something like a third of the total effort going into the workflow itself, and it changed in response to measured pain rather than fashion.

Why this matters for enterprise software

None of this is really about any one project, and none of it is about replacing developers. It is a way to get the genuine productivity gains everyone is promised without the things that usually come bundled with them: code shipped unreviewed, a graveyard of proof-of-concepts, quality quietly traded for speed. The agents do the volume; humans keep the judgment and the taste. Architecture, security, and performance each get a dedicated reviewer instead of being an afterthought. And because the whole workflow is versioned, a team owns it and keeps improving it – rather than renting a black box.

That last point is where this connects to the work we do at itemis. Getting AI to really land in an organisation is less about the model and more about the workflow around it – the right tools, clean integration into existing systems and quality gates, and people who can keep shaping it after the consultants are gone. Vertical agents and horizontal skills are one concrete shape that workflow can take. If you are trying to move past clever autocomplete toward agents you can actually delegate to – and to do it without abandoning the engineering practices that kept your software trustworthy in the first place – that is exactly the kind of problem we like to work on.

itemis · AI-Enablement — We help enterprise teams put AI to work in software development – choosing the right tools and models, integrating them into existing systems and quality gates, and building agentic workflows your people own and keep improving. No vibe coding, no AI theatre. Learn more about AI-Enablement →