← Back to blog
Ilustración conceptual: una mano trazada con líneas de luz emerge de un campo de fragmentos de datos y se prolonga hacia la derecha en ondas de código y nodos conectados.

Agentic development consulting

ConsultingAgentic developmentMCP

Almost every team I meet has already tried coding agents. The story repeats itself: someone installs Copilot or opens a chat, the first demo generates a spectacular function and, three weeks later, the team's verdict is that it produces bad code or outright smoke.

The diagnosis is usually wrong. The problem isn't the model: it's that the agent works blind. It doesn't know your architecture, it can't see your logs, it doesn't know how a PR is opened in your repo or what conventions your team follows. An agent without context hallucinates fluently.

Agentic development is building that context infrastructure —and the way of working around it— so the agent stops guessing. That's what I offer as consulting, and what I use myself every day.

What agentic development really is

It's not giving developers a chat. It's a work system in which the agent:

  • Reads your code against a real index of the repository, not with plain-text search.
  • Queries your systems: logs, database, framework documentation, tickets.
  • Runs the full cycle: branch, commit, PR, CI, and fixing the failures it causes itself.
  • Works under human control: every change goes through review, like any teammate's.

The difference from autocomplete is one of kind, not of degree. And the difference from “AI that codes by itself” is that here a human directs and reviews every step.

What gets built: the context infrastructure

This is what separates a useful agent from one that makes things up. The concrete pieces, as I have them set up in this repository:

  • A devcontainer as the agent's home. The whole team —human or not— works inside the same reproducible environment. This portal's spins up Postgres, Keycloak, Typesense, and the model gateway; the agent lives in there, with the same tools and services as me.
  • Custom MCP servers. MCP is the protocol the agent uses to talk to your systems. In this project: logs in Loki/Grafana, GitHub for PRs and reviews, read-only Postgres, Playwright for testing the web, Payload and Next.js documentation via llms.txt, and the CMS itself. Every team needs its own; setting them up is part of the work.
  • Documentation written for the agent. An AGENTS.md at the root that orients the agent the way you'd orient a new teammate, and skills with the team's procedures —including the skill used to write this blog's posts—.
  • The indexed codebase. GitNexus keeps this repo mapped: 4,925 symbols, 11,501 relationships, and 300 execution flows. Asking “what breaks if I change this” stops being an act of faith.

There's data behind these decisions. LangChain benchmarks show that llms.txt plus an agent that reasons about which pages to consult outperforms an embedding-based RAG for framework documentation; the Claude Code team works without any indexing at all, only with agentic search. Less heavy infrastructure, more judgment.

The specification rules: spec-driven development

Context tells the agent where it is; it still needs to be told what to build. For that I work with spec-driven development, and specifically with SpecKit: every feature is born as a numbered specification in the repo —spec.md, implementation plan, task list— that a human reviews before the agent writes a single line. The prompt is forgotten; the spec remains.

At Konect we took it to the extreme: a project constitution versioned with semver —yes, with its own release notes— and ten specs per feature, from audio transcription to reports. The agent implements against the spec, not against what it remembers from a conversation.

And right now I'm applying it in a demo of my own: an event-driven flow and survey engine in TypeScript, built entirely spec-driven. The core and the React adapter already work with their tests; the MCP adapter is the next spec in the backlog. Every piece has its spec, its plan, its contracts, and its tests. It's the cleanest way I've found to get an agent to code what you asked for, and not what it understood.

How the work gets done: a real morning in this repo

This happened exactly as told, while developing this portal. I have the full transcript:

  1. I ask the agent to check the environment logs in Axiom. It lists the datasets, runs its queries, and comes back with a diagnosis: more than a thousand errors in 24 hours, an invalid value arriving as a parameter to the admin's taxonomy filter that breaks the Drizzle queries.
  2. I ask it to split the work into two separate PRs. It classifies the touched files, creates the branches, commits, and opens PRs #59 and #60, each with its summary and its test plan.
  3. CI on PR #60 fails. The agent reproduces the failure locally, rebases onto main, fixes the lint, and amends the commit with --force-with-lease.
  4. A review bot (Devin) leaves an accurate comment: the regex \s{2,} was also swallowing line breaks and mangling the markdown before indexing it. The agent evaluates the comment, applies the suggested fix, and updates the PR.

None of these steps is magic: I set what needs doing, the agent executes, and everything ends up in PRs that a human reviews before merging. That's the dynamic to instill, and it's very different from throwing out a prompt and crossing your fingers.

Where the experience comes from

I'm not selling a methodology read in a report. This portal —the site you're reading— is built exactly this way: devcontainer, its own MCP servers, a model gateway with egress locked down, and ephemeral PRs with their own environment. And this very post was written by an agent with that workflow: the house writing skill, the repo sources, and a custom script that compiles Markdown to Payload.

Before, at Konect, we set up the same idea in a larger team: devcontainers for everyone and a full preview environment for every pull request. The conviction is the same in both places: the environment is part of the team, and an agent is only useful when it lives inside it.

When it makes sense (and when it doesn't)

It fits if your team has a real repo, CI, and code review, and you've tried agents without seeing results. Also if you're worried about giving your code away to third parties: the setup lives inside your infrastructure, model access goes through a gateway you control, and when the problem demands it, the work is done with private models.

It doesn't fit if there are no tests, no CI, and no habit of reviewing code: the agent amplifies what it finds, and without those foundations it amplifies the chaos. Nor if what you're after is “AI that codes by itself” with nobody reviewing.

Related consulting

El editor de Flowgraph con un cuestionario de prueba: el nodo de página inicial enlaza con «Datos de contacto» cuando la respuesta es afirmativa y con el nodo de resultado «completado» en cualquier otro caso, mientras el editor marca el flujo como válido y navegable.

Flowgraph: a flow engine built spec-driven

LabFlowgraph
Las dos mitades del montaje, separadas por una diagonal. A la izquierda, sobre fondo oscuro, la gráfica de coste por modelo de Langfuse a lo largo de tres meses, con el gasto acumulado del periodo. A la derecha, la tabla de la pasarela: cuatro alias estables —chat-estandar, chat-premium, razonador y economico— apuntando a modelos de cuatro proveedores distintos, cada uno con su coste de entrada y de salida por millón de tokens.

LLMOps on your own cluster with LiteLLM, Langfuse, and ArgoCD

LabLLMOps
El panel de Huygens: a la izquierda el diario por fechas, en el centro el grafo con las propuestas del día —nodos marcados como nuevos o editados, con sus cambios de estado y sus bloques—, y a la derecha los informes narrativos que el agente redactó sobre cada corrección.

Huygens: a SurrealDB graph as memory for agents

LabAgents
Listado de organizaciones en Keycloak: dieciséis clientes conviviendo como espacios separados dentro de un mismo despliegue.

One deployment per customer or one space per customer

ConsultingMulti-tenancy
Gobernanza de IT

IT governance: who gets in, who can deploy, and how you prove it

ConsultingGovernance
El explorador del grafo HERM en modo taxonomía, ampliado sobre el núcleo del estándar: los elementos de HERM v3.0.0 colgando de una raíz común —capacidades de negocio en azul, entidades de datos en verde y componentes de aplicación en naranja—, con el código de catálogo de cada nodo legible y el panel marcando 421 nodos y 420 enlaces.

From standard to graph to project

Case studySingular Solving

Let's talk

If your team has tried agents and come away disappointed, it's almost certainly missing context, not model. Tell me how you work and I'll tell you what I'd set up first.