As a professional services company, it was important that if we’re going to help our customers understand where agents can add value, we need to have used them ourselves in real processes, with real data, and real constraints.
So over the past year, we’ve been progressively introducing agents into the way we run Ignite. Here are some of the lessons we’ve learned.
Blue-sky thinking is surprisingly hard
One of the hardest questions to answer is Where should we use an AI agent?
Starting with a blank sheet and trying to imagine transformational use cases sounds appealing, but we’ve found it isn’t particularly productive. Instead, we’ve started looking for processes where there is significant deliberation across multiple people.
These are often processes where there isn’t one obviously correct answer and the deliberation (in the guise of collaboration) becomes inefficient.
Incident and service-request triage is a good example. What type of request is this? How important is it? What might the impact be? Have we seen something similar before? Is there enough information to act? People interpret these questions differently.
That’s exactly where an agent can be useful, not necessarily to make the decision, but to provide a consistent and well-reasoned starting point.
Interestingly, AI’s tendency to produce a definitive answer can become useful when applied to a process that is inherently ambiguous. It forces an initial interpretation that a person can then challenge, refine or approve.
Start much simpler than you think
Some of our most useful early agents weren’t particularly sophisticated. Our Quarterly Health process is a good example.
We initially used an agent to review uploaded platform-health findings and produce a first-pass summary and recommendations. There was no complex integration. No large historical knowledge base. No elaborate orchestration. And it was surprisingly good.
That was important because it allowed us to test the value of the reasoning before investing in the plumbing.
Once we’d seen the results, we could justify integrating the agent with other systems and enriching the context available to it. Our lesson has been: don’t try and build the ultimate agent first, it probably won’t get past idea stage. Prove that the agent can perform the job, then progressively give it better tools, context and data.
Build agents where the data already lives
Even as a company that specialises in modern data platform delivery, we’ve resisted the temptation to create a single AI technology stack for every agent. Instead, wherever practical, we’ve used the AI capability within the application where the work and data already reside. It reminds me of the old debate around operational reporting being in operational systems.
For example, we’ve used Rovo for agents working with Jira because that’s where the underlying delivery information lives. That does mean we may ultimately have agents operating across several technology stacks. But not sure that’s necessarily a bad thing.
Moving and replicating data simply to enable AI introduces integration effort, governance considerations and another source of information that needs to be maintained. Where there is a genuine reason to bring information together, we do it. But our starting position has become:
Take the agent to the data before taking the data to the agent.
Agents can be a form of governance
One of the less obvious benefits we’ve found from building agents around specific business processes is governance.
Without a defined agent, the alternative isn’t necessarily that people won’t use AI. Increasingly, they’ll find their own way to use it.
That can mean different people using different AI tools, writing different prompts, producing different interpretations of the same information and potentially moving data into places it shouldn’t be. A purpose-built agent changes that.
If someone needs an incident triaged, there’s an agent designed specifically for that process. If they need a risk assessed, there’s another. If they need platform health findings interpreted, we have an agent for that too. The agent provides a defined pathway for using AI within that process. That means we can be deliberate about what data the agent can access, which model and technology it uses, the instructions and context it receives, the output it produces and where human judgement and approval are required.
It also creates consistency. Rather than ten people developing ten different prompts to perform essentially the same task, we can improve the agent once and make that improvement available to everyone using the process.
So we’ve started to see agents not simply as another way to introduce AI into the organisation, but potentially as a way of reducing uncontrolled AI use.
The principle is relatively simple: Don’t just give people AI. Give them a governed way to use AI for a particular job.
Embrace Version 2.0
We’ve stopped thinking about an agent as something that gets “finished”.
Our Quarterly Health agent started with document uploads. The next version integrated with internal applications. The next is evolving again as we explore integration with a stronger LLM and richer context. Each version teaches us something about what the agent actually needs.
That has changed how we approach development. Rather than trying to anticipate every requirement upfront, we deliberately start with a narrow job and incrementally add capability. We’re very comfortable saying This is Version 1.0. Because we expect there to be a Version 2.0.
The technology and the economics keep moving
One challenge that’s easy to underestimate is how quickly the commercial and technology landscape changes.
Databricks, Jira, Microsoft Copilot, Claude and other platforms continue to evolve their AI capabilities, commercial models and approaches to data. That means the design decision we made six months ago isn’t necessarily the decision you’d make today.
Cost, security, data privacy, model capability and where information is processed all need ongoing attention. For us, agent design isn’t a one-off technology decision, it’s something we expect to revisit regularly. However, we anchor these decisions to the process it is solving for to avoid over thinking and over designing.
Finally, give the agent a name
There’s one other practice we’ve adopted that initially might sound a little superficial, and started out as a bit of fun. We name our agents.
We’ve started to think about agents as part of a hybrid workforce, rather than as technology designed to replace people. And we’ve found that giving an agent an identity helps us get much clearer about its job.
👩💻 Triage Trish is our first point of triage.
She reviews incoming incidents and service requests, finds similar incidents, anticipates potential impact, proposes priority and target dates, and asks for clarification when there isn’t enough information.
⚠️ Risky Rick helps us manage risk.
Rick helps identify and articulate risks, assess their likelihood and impact, and suggest mitigations, giving our team a better starting point for making decisions.
🩺 Quarterly Health Quinn helps assess the health of the data platforms we manage.
Quinn reviews the evidence, identifies areas of concern and recommends actions based on platform health, with our architects providing the judgement and context.
None of these agents owns the final decision, as that remains with our people.
The agents perform more of the repeatable analysis, preparation and first-pass work, freeing our people to focus on judgement, relationships, creativity and accountability.
Naming has also had a surprisingly practical effect with our people knowing who does what.
“Send it to Trish.”
“What did Quinn find?”
“Get Rick to assess it.”
Instead of saying “use AI to help with this”, we’re directing work to a capability with a defined role, defined context and defined boundaries.
The question for us is becoming less about “Where can we use AI?” and more about “How should we divide the tasks between people and agents?”
What job should the agent perform? What information should it have access to? What decisions can it support? Where does human judgement begin? How does that role evolve as the technology improves? And how do our processes benefit?
