How we use AI agents to help software teams deliver with less friction

Every software project comes with a layer of work around the code: turning decisions into tickets, keeping documentation current, setting up repositories, preparing pull requests, moving tasks through workflows, and rebuilding context across teams and tools. Each task may seem small, but together they consume focus and slow delivery.

That is the challenge behind Ambrosia, an initiative that began in our R&D Hub as an exploration of how AI agents could work alongside software teams. Today, the systems and practices developed through Ambrosia are being used in production and applied within client environments.

The goal is not simply to generate more code. It is to reduce the operational friction surrounding development, helping teams move from intent to delivery with greater clarity and momentum.

As we continue deploying and refining these approaches, we are launching a series on agentic engineering to share what we are building, what we are learning, and what organizations should consider before introducing agents into their own software delivery workflows.

From assistant to delivery system

For the past few years, most conversations about AI in software development have focused on individual productivity: code suggestions, documentation support, faster research, and better autocomplete.

Those tools are useful, but we wanted to explore a different question: What happens when AI agents become part of the development workflow itself?

Ambrosia began as our way of testing that question in a real software delivery context. It has since evolved into a production-ready approach that we are applying to our own work and adapting to the realities of client software environments.

Instead of using AI only as a tool for one person, Ambrosia looks at how specialized agents can help a team move work forward. Agents can help interpret project documentation, create structured tickets, update documentation, prepare pull requests, review changes, and support the movement of tasks through defined workflows.

The goal is not only to automate parts of development. It is to remove some of the operational noise around it, while keeping people responsible for direction, quality, judgment, and decisions.

Why a multi-agent approach matters

One of the important choices behind Ambrosia is the use of multiple focused agents instead of one large assistant trying to do everything.

Software delivery is made of many small but connected activities. Some require deep technical judgment. Others are more repetitive or process-driven. By giving agents narrower responsibilities, we can make their work more structured, easier to evaluate, and easier to review.

This also makes parallel work possible. Different agents can contribute to different tasks at the same time while staying within clear boundaries.

For us, this is where agentic development becomes interesting. It is less about asking AI to “build the thing” and more about designing a system where agents can support the team in specific, useful ways.

Less admin, more engineering

The biggest value of Ambrosia is not only speed. It is the reduction of friction.

A ticket with poor context slows everyone down. Outdated documentation creates confusion. Manual project setup takes time. Small coordination tasks interrupt focus. Pull requests need to be prepared, reviewed, and moved through the right steps.

None of these things are dramatic on their own. But together, they shape the pace and quality of delivery.

Through Ambrosia, we have developed and deployed agents that can take on some of this work within real delivery environments. One agent might turn raw notes or project documentation into clearer tickets. Another might update documentation or prepare a pull request for review.

Agents can also navigate large volumes of information, including technical documentation, meeting transcripts, project decisions, tickets, and software specifications, to surface relevant context when developers need it.

That context can also be used during implementation and review. A development agent can interpret software documentation, story tickets, domain knowledge, and project-specific conventions while fixing bugs or developing features. A review agent can evaluate changes against acceptance criteria, software requirements, architectural decisions, and other information associated with the work.

Over time, this allows agents to function less like generic assistants and more like project-specific technical collaborators.

For developers, that can mean less time reconstructing context across disconnected systems and more time focused on architecture, problem-solving, trade-offs, and client context. In other words, the work where their experience and judgment matter most.

Ambrosia in practice

Ambrosia is already being used across six projects, including client work, internal initiatives, proofs of concept, and demonstration projects. At the time of writing, teams have been working with it for periods ranging from approximately one week to five months, with the depth of adoption varying from one project to another.

Rather than applying the same setup everywhere, teams are adapting Ambrosia’s harness to the needs, tools, and development practices of each project. This has allowed us to explore where agents are most useful across different parts of the software delivery lifecycle.

So far, Ambrosia has been used to support:

• Development workflows: implementing tickets, generating tests, applying project-specific programming practices, preparing pull requests, updating ticket status, enforcing contribution conventions, and validating infrastructure.
• Project management: connecting project trackers, version control systems, and coding agents to help draft, structure, and create tickets.
• Code quality: reviewing changes against acceptance criteria, evaluating the impact of refactors, supporting test-driven development, and keeping documentation aligned with the codebase.
• Design implementation: translating Figma designs into React components while preserving layout, spacing, typography, colours, and other visual details.
• Documentation: producing and maintaining consistently structured project documentation.
• Architecture and experimentation: helping teams reason through technical approaches and develop solutions in unfamiliar domains.

These deployments are still at different stages, so we are cautious about drawing broad conclusions from them. What they are already showing us, however, is that the value of agentic development extends well beyond code generation.

Teams are finding opportunities to use agents across the surrounding workflow, particularly where context needs to move between tools, repetitive steps can be automated, or project-specific knowledge needs to be applied consistently.

Developers as orchestrators

As agents become more capable, the role of the developer evolves.

Developers still need strong technical skills. But they also need to become better at framing work, giving context, reviewing outputs, validating decisions, and knowing when to step in.

In an agentic workflow, the developer is not just producing code. They are orchestrating work.

That shift is important. It asks teams to build new habits around clarity, review, and accountability. It also creates a different kind of leverage. A developer who knows how to guide agents well can help the team move faster without lowering the bar on quality.

It also changes what good inputs look like. Clear tickets, documented decisions, well-defined conventions, and accessible domain knowledge become even more valuable when both people and agents rely on them to make decisions.

Governance from the start

Agents that can take action need clear limits.

In software development, an agent may interact with codebases, command-line tools, documentation, tickets, and project environments. That creates real risks if the system is not designed carefully.

With Ambrosia, governance is part of the architecture. Agents need boundaries. They need controlled environments. They need the right permissions for the right task. They need to follow the same workflow logic as the team.

This is especially important in client work, where context, access, and data separation matter.

For us, responsible agentic development is not about giving agents as much power as possible. It is about giving them the right scope, with the right controls, so they can be useful without creating unnecessary risk.

What we are learning

Ambrosia started as an internal R&D initiative. As it moved into production and client delivery, it began raising broader questions about how software teams should be structured in an agentic environment:

• How do we design workflows when some tasks can happen in parallel through agents?
• How do we train developers to work effectively with agentic systems?
• How do we maintain quality when humans and AI both contribute to delivery?
• How do we preserve accountability when agents can take action across tools?
• How should project knowledge be structured when both people and agents depend on it?

These are questions we are addressing through the continued development and deployment of Ambrosia.

We do not see agentic development as a shortcut. We see it as a new way to structure work. Done well, it can reduce friction, improve access to context, and give developers more time for the work that requires human judgment.

This article is the first in a series where we will share what we are learning as we deploy, refine, and scale agentic engineering practices in real software environments.

For organizations exploring how agents could improve their own software delivery workflows, our team can help identify the right use cases and turn those opportunities into production-ready systems. Reach out to our team if you have any questions.