Layering Artificial Intelligence on the platform to surface relationships, enable real-time exploration, and let users interrogate complex agricultural data on their own terms
~60% asked their first question in their first session
Ask Oracle lived in the existing search bar, so the mental model carried over with no training, docs, or onboarding.
Time on the insight page roughly doubled
From ~4 minutes to ~9, mostly spent in relational questions and scenario comparison, evaluating cost, impact, and time-sensitivity.
~7 in 10 short-form questions rolled into long-form chat
Users continued in context with the original insight rather than restarting somewhere else.
Agricultural intelligence systems already surfaced data across weather, land use, crop performance, and infrastructure. Users could access signals, explore datasets, and build their own interpretations. But understanding how these signals related to each other was still largely manual, teams had to piece together how variables interacted across time and geography, whether emerging patterns were meaningful, and what those patterns implied for action. This often relied on internal heuristics, spreadsheets, or templated workflows built outside the system.
Even where insights existed, they were static — surfacing conditions without context. The UI below was the state-of-the-art before the redesign.
An insight might flag low vegetation index in a region. It didn't explain what was driving it, how it related to other variables, or whether action was required — the analyst was still left to interpret meaning and determine next steps.
Through extended work with government teams, I mapped how decisions are actually made in practice, not just how the system is designed to work. At a surface level, data is already available. Dashboards surface signals across weather, crop performance, and land use, and users can access multiple datasets without friction. But reaching a decision requires work that happens outside the system.
Mayeso has a major meeting coming up with government leaders, where she'll need to present updates on the country's food production trends and how it's affecting food security.
She is already dreading the process, the data she needs is scattered across various sources, and she knows it's going to take significant effort to pull it all together.
Mayeso starts her workday by logging into several government systems. She opens multiple spreadsheets and databases, each in inconsistent formats. Some files are missing critical information, and she knows she'll have to fill in the gaps later.
She can't help but feel overwhelmed, knowing it will take days, if not weeks, just to get the data organised.
Mayeso spends the better part of the week searching for relevant crop production data by year, county, and crop type. For some counties, the data is incomplete or outdated, meaning she will have to contact regional offices to request updates.
This adds another layer of complexity to an already tedious process. Once she finally finds the files she needs, the process is slow, large file sizes and sluggish server speeds hold her back.
Now, Mayeso faces the challenge of merging data from multiple files into one spreadsheet. She spends hours aligning columns, correcting formats, and ensuring the data is consistent.
Every step requires careful attention to detail because one mistake could compromise the entire analysis.
After hours of cleaning the data, Mayeso is left with a massive spreadsheet and no clear direction. The numbers blur together, and she struggles to understand what data she should pull for leadership.
She knows there's valuable information here, but it's hard to pinpoint what matters most. She decides she'll need to spend more time digging through the data, trying to pull out information that could help guide decisions.
Mayeso finally begins creating visualisations. Using Excel, she develops pivot tables and charts to show trends in crop production over the past decade, comparing them with future projections.
As she works, she feels drained but focused. She knows that if any errors slip through, it could impact the conclusions she draws.
With the visualisations complete, Mayeso starts analysing for trends. She quickly realises the extent of the drought's impact in Trans-Nzoia, much of the crops are already dead, and the damage is irreversible.
It's frustrating because by the time she uncovers these data points, it's too late to take meaningful action. Even worse, all the data she has is historical, leaving her no insight into how the situation might evolve.
On the day of the meeting, Mayeso is anxious. Despite her efforts, leaders focus on missing data from key regions. Unable to trust the report, they spend the entire meeting asking clarifying questions she can't answer.
The meeting ends without decisions, only with agreement to collect more data and reconvene.
The same patterns came up across every conversation and every step of the current state. They aren't observations about the UI — they're observations about what happens to the analyst between a signal arriving and a decision being made. Drag any note around; they live as a pile, not an ordered list, because that's how they came up.
Most effort is sense-making, not access
Mayeso doesn't struggle to get the data. The hard part is figuring out what it means once she has it.
Analysis is mostly assembly
Hours stitching fragments across datasets, validating completeness, reconstructing context through external tools — long before any actual interpretation begins.
One hour to brief from scratch
When a minister calls with a question no one saw coming, the analyst rebuilds the answer from raw sources. Every time.
Visibility without connection
The platform shows what is happening. It doesn't explain how the signals relate, whether patterns are emerging, or what those patterns imply.
Interpretation lives in heads, not the system
Every analyst reads the same dashboard differently. Conclusions depend on individual experience rather than a shared framework.
Signals arrive after the damage
By the time the data confirms a drought, the crops are already gone. The system tells you what happened, not what's about to.
Observation, not understanding
The signal-to-decision jump is manual. The system supports observation; the analyst has to do the rest, alone.
Previously, insights were framed as indicators. They surfaced key metrics, often expressed as percentages or risk levels, sometimes accompanied by short projections based on known conditions. For example, an insight might indicate that a percentage of crop production in a region was at risk, with a note that conditions were expected to worsen over time.
While useful, these insights still required interpretation. They described the state of the system, but left users to infer what was actually happening, how it was evolving, and what it meant in context.
The redesign focused on expanding what an insight represents.
Instead of summarising risk, insights were structured to support different layers of understanding, moving from describing current conditions to explaining causes, projecting outcomes, and indicating possible actions.
Each insight now spans description, explanation, projection, and action, removing the need for users to piece that progression together themselves.
Three rules every insight has to clear before it earns a slot in the UI.
Insights propose what's happening and why — they never assert it. Users keep the right to question, validate, or override.
Every conclusion drills down to the underlying signals and the variables that shaped it. Confidence comes from being able to audit, not from being told to trust.
Each rule was tested against what product needed, what data could reliably surface, and what engineering could generate at scale. UI clarity and system feasibility were decided together.
Interrogating a system goes beyond restructuring insights, and we knew it didn't have to be another chatbot to do it. The mental model of searching and asking questions sits close to one another, and the search bar around an insight is already where the questioning starts. So we used that surface, Ask Oracle, where every query already happens, as the entry point into deeper inquiry.
Inside the search barWe started with short-form interrogation, very quick answers, in context. Think of an SOM meeting where someone asks a focused question and needs a concise, grounded answer without breaking the flow of the discussion.
But certain contexts call for going deeper. That's where Ask Oracle morphs into a sidebar chat, only when the user wants to continue in the same line of thought. The history is kept in this surface, so users can revisit prior questions and keep extending the inquiry without restarting.
Both modes stay grounded in the same data the insight draws from, so any answer can be traced back to its source without leaving the page.
Understanding what is happening is only part of the problem.
Once the analyst and their team have clarity, they still need to decide what to do, often under time pressure, uncertainty, and competing constraints.
Previously, this process happened outside the system. Teams would take insights, move into spreadsheets or separate tools, and manually model possible interventions. Comparing outcomes, weighing trade-offs, and aligning on a direction could take days or weeks, especially when decisions involved multiple variables and stakeholders.
The redesign extended the system from interpretation into decision modelling.
Instead of treating action as a separate step, users can now explore possible responses directly through natural language, testing how different decisions might play out without leaving the workflow.
Scenarios can be revisited, refined, and shared, allowing teams to build decisions collaboratively without reconstructing the analysis each time.
Measuring whether AI in a workflow tool actually works is genuinely hard. We deliberated for weeks on what to track, accuracy benchmarks, response time, satisfaction scores, and most of them didn't tell us anything useful about whether we'd built something people would keep using. What we landed on isn't perfect, and it's still being iterated on, but these three are the closest proxies we have for what changed.
Still iterating on metricsAsk Oracle lives where the existing search bar lived. Users who already knew how to search the platform now had AI grounded in the same data, no new behaviour to learn, no separate destination to go to. We didn't write docs, build training material, or run onboarding sessions, and ~60% still asked their first question in their first session. The decision to live in the search bar wasn't a UI choice; it was the adoption strategy.
Average time on the insight page rose from ~4 minutes to ~9. Almost all of the new time went into relational questions, what's similar in past seasons, why this region, and into scenario comparison, where users evaluated cost, impact, and time-sensitivity before committing to a decision. We weren't trying to make insights faster to read. We were trying to make decisions slower, and better-considered. The platform held attention because it gave people room to deliberate. That deliberation was the point.
The most consistent behavioural signal was that short-form interrogations rarely ended at the answer. Roughly 7 in 10 rolled into the longer chat surface, where users continued in context with the original insight rather than restarting somewhere else. In retrospect, short-form wasn't a self-contained tool; it was the entry point into deeper interrogation. Whether "follow-up rate" is the right thing to measure is part of what we're still working out.
While building this layer, the question that kept coming up was how to measure whether it worked. The honest answer is that traditional metrics, queries served, accuracy benchmarks, time-to-answer, don't capture what we set out to do. What we landed on is simpler: AI is supposed to be useful in making the work better. That's the bar.
Not all AI needs to be a chatbot. Sometimes the most useful thing an AI can do is sit inside an interface someone already understands, and answer questions they're already asking. The mental model for "I want to find something" is search, and people have decades of muscle memory there. A new sidebar, a new tab, a new "AI Assistant" surface, all of those ask the user to learn a second platform on top of the one they came to use.
Which is why we put it in the search field. The mental model was already there: people were searching for answers. We just made the platform able to give them. The lesson, if there is one, is that the right interface for AI is not always a new interface, sometimes it is making the one that already exists smarter, on the user's terms, in their flow.