An agent that turns a ticket into a finished pull request looks impressive in a demo. In an enterprise, it meets twenty-year-old code, three approval bodies and a security team that rightly asks questions. Here is what we’ve learned.
Agents need small, clear tasks
The more precise the task, the better the result. “Build the new customer portal” doesn’t work. “Update this library across all services and fix the tests” works surprisingly well. The best starter tasks are important, recurring and unpopular.
Context beats model
The strongest model is of little use if it doesn’t know the architecture. The biggest lever is giving agents the right context: coding guidelines, architecture decisions, domain terms, examples of good code. Capture that knowledge in a structured way and you help agents - and new colleagues too.
Events, not chat
In practice, agents are rarely started by hand. They react to events: an issue gets a label, a build fails, a dependency has a vulnerability. That makes them teammates working in the background rather than tools you have to operate.
Humans stay in the loop - at the right point
Agents shouldn’t write directly to the main branch. The pull request is the natural approval point: the team sees what changes and why, and can reject it. Work shifts from writing to reviewing - and review becomes a core skill.
Security from day one
- Agents run in isolated environments with least privilege.
- Credentials are short-lived and scoped to the task.
- Every action is logged - traceable for audits.
Where it fails
Not on technology. Agentic development fails when nobody owns the agents, when results aren’t measured, or when teams feel replaced rather than relieved.
Our advice: start with one team and one class of task, measure properly, then scale.
