I don’t want Tereo AI Technologies to enter a community, install technology and leave behind a system that only we know how to operate.
If we build water infrastructure, the people using it should eventually understand how to maintain it. If we introduce technology into agriculture, local operators should know what the system is measuring and why. And if artificial intelligence is helping make decisions that affect people, a human being should remain accountable for the final decision.
That is the kind of company I am trying to build.
At Tereo AI Technologies, our work stretches across clean water, agriculture, healthcare, autonomous infrastructure and public safety. On paper, that can look like several different businesses. I see them as parts of the same problem.
Too often, technology arrives with dependency built into it.
The company owns the system. The company understands the system. The company controls the technical knowledge. When something goes wrong, the community waits for the company to return.
I want to build differently.
Build It, Then Teach People to Run It
At Tereo, we call our approach Teach, Build and Replicate.
The idea is straightforward. We teach people how the technology works. We build alongside them. Then we work toward a model that can be operated, expanded and replicated without requiring Tereo to control everything permanently.
That means I don’t measure success only by whether we installed a piece of infrastructure.
I want to know what remains locally.
Are there people who can maintain it? Did the project create skilled work? Can the community operate the system? Could what we built in one location eventually be replicated somewhere else?
Those questions become particularly important in Africa.
The continent produces crops, minerals and other resources that enter global value chains. But producing the raw material does not necessarily mean capturing most of the economic value attached to it.
A crop can be grown in Africa and processed elsewhere. A mineral can leave the continent before becoming a component. The finished product can then return at a much higher value.
I believe more of that chain can remain closer to where the resource originates: processing, manufacturing, assembly, distribution and skilled employment.
That thinking influences the infrastructure we are developing.
Why We Started With Water
One of those projects is Aqua Vivae, our approach to water infrastructure.
Water touches almost everything else we want to build.
A farmer needs it. A community needs it. Industrial facilities need it. Data centres need it. Public health depends on it.
So I don’t think about water simply as something flowing through a pipe. I think about the wider system around it.
In an agricultural setting, for example, water quality can be considered alongside soil conditions, irrigation requirements, crop needs, available energy and operational data.
A farmer or operator should be able to see what the farm required and compare it with what the system actually delivered.
That creates the possibility of making decisions from current conditions rather than assumptions.
But there is another part of Aqua Vivae that matters just as much to me.
Someone locally should understand how it works.
The equipment needs technicians. The information needs people who can interpret it. The system needs people capable of maintaining it when the original developers are no longer standing beside it.
Otherwise, we have solved one problem by creating another dependency.
Then I Asked Who Challenges the AI
Building connected systems also forced me to confront a different problem.
Who tells the artificial intelligence that it might be wrong?
We are moving towards a world in which AI will increasingly make recommendations about physical systems. That becomes much more serious when the subject is water, agriculture, healthcare or autonomous equipment.
A confident answer from an AI system is still just an answer.
I wanted our architecture to challenge that answer before somebody acts on it.
That thinking became Gabriel.
The simplest way I describe Gabriel is:
The Architect creates.
The Destroyer challenges.
The human decides.
The Architect examines available information and develops a recommendation.
The Destroyer has a different job. It looks for weaknesses in that recommendation. What information might be missing? Could a sensor be wrong? What happens if the weather changes? What if communications fail? What has the first system assumed that it should not have assumed?
Then the human sees both sides.
The purpose isn’t to make AI argue with itself for the sake of it. I want important recommendations challenged before they affect people or physical infrastructure.
And there is a boundary I don’t want to remove: final authority remains with a person.
AI can calculate faster than we can. It can compare enormous amounts of information. It can identify patterns, make recommendations and flag risks.
But when a consequential decision has to be made, somebody should still be accountable for making it.
Gabriel Is Meant to Travel Across Our Systems
We are designing Gabriel as an architecture that can work across the different areas Tereo is developing.
With Aqua Vivae, that could mean evaluating water quality or irrigation requirements and then challenging a recommendation against faulty sensors, changing weather, equipment problems or power constraints.
In agriculture, it could compare what a crop requires with what is actually being delivered.
In healthcare, information from wearable devices and room sensors could be examined and challenged before an alert reaches a caregiver or clinician.
For autonomous infrastructure, a proposed mission could be tested against weather, communications, equipment readiness, operating restrictions and safety boundaries before a human gives final authorisation.
Different applications create different risks. My principle remains the same: an important recommendation should not become trustworthy merely because an AI produced it.
Why Ownership Matters to Me
There is a personal reason I think so much about systems, control and the people affected by them.
I experienced foster care and homelessness as a teenager.
I learned early what it felt like to live inside systems that could make decisions about your life while you had very little power over those decisions.
That experience is part of me, but I don’t want survival to become the headline of everything I do.
What interests me now is what I can build.
Tereo gives me an opportunity to think about systems from the other side. If we have the power to design technology that enters somebody else’s community, what responsibility comes with that power?
For me, part of the answer is ownership.
I don’t want to enter African communities presenting Tereo as the company coming to save anybody. Local farmers understand their farms. Engineers understand the operating environment. Families understand their communities. Local leaders understand realities an outside developer may never see from a spreadsheet.
Our job should be to build with that knowledge, not over it.
And I want the economic opportunity surrounding the technology to extend beyond Tereo.
People should be trained to install systems, maintain equipment, interpret information and manage operations. Skills should become jobs. Jobs should have the opportunity to become careers. Local operators should become capable of teaching other operators.
Eventually, the community should need less from us, not more.
Some companies might see that as giving away control.
I see it as evidence that the model worked.
If we leave behind infrastructure that people cannot operate without us, then Tereo remains valuable to that community.
But if we leave behind infrastructure, knowledge, skilled people and the ability to build the next system, the community becomes more valuable to itself.
That is the technology company I want to build.
Tess McCleary is the founder of Tereo AI Technologies, and her work spans AI, healthcare, water infrastructure, autonomous systems, agriculture, logistics, manufacturing and human-support technology.
