I don't see AI as a chatbot. I see it as a different way to work.

I'm Meelis Sootalu, and OEJ started from one practical question: how much real work can you hand to AI when the system around it is built properly?

Not as another demo. I'm interested in systems that research, compare, write, check their own work, use tools — and get through a real part of the day that would otherwise eat hours.

But the more interesting half is the other one: how do you know the result is any good?

Most of what I've built lately has been me trying to answer that.

What I've actually built with AI

My own AI agent

I have an AI agent running on a private server that I use every day — for research, audits, analysis, writing, and directing other agents.

It has persistent memory, its own knowledge base, tools, scheduled tasks, and more than a hundred reusable skills and procedures.

The count isn't the point. The point is that it doesn't start from zero every time: a lesson learned once becomes part of the system and is there the next time.

A World Cup prediction system

For the 2026 World Cup I built a system that combined statistical modelling, current research, source verification and strategic decision-making.

It predicted 103 of 104 matches and finished 2nd out of 18 participants.

The result wasn't the interesting part. What emerged during the tournament was that the biggest gains didn't come from a smarter model — they came from fixing the process: which sources to trust, how to handle draws, when the system should ask again, and where a human has to confirm the call.

Which is really the whole lesson: process beats picking the cleverest model.

A customer support tool

I've also built a tool that searches a large documentation base and drafts customer support answers in the customer's own language.

The first question on that project wasn't "which AI model should I use?".

It was: how do I keep a customer's name, email address, company name and device identifiers from ever reaching the model?

So the privacy layer came first. Sensitive details are stripped locally and checked again before anything moves. If that check fails, the job stops. Not "continues with a warning". Stops.

Boundaries before features. Better to find the limit before you build the capability.

A production web platform

I've used AI agents to direct the development of a substantial production web platform — from research and specifications through implementation, testing, browser audits and release verification.

There's no single all-knowing AI in the middle of it. Planning, building and review are separate jobs, and whoever built the thing doesn't get to sign it off. Claims need evidence — and when something genuinely can't be verified, "can't verify" is a perfectly good answer. I'll take that over a confident green tick any day.

How I think about it

1. Evidence before confidence

AI can sound completely sure of itself and be flat wrong. I want to see where a number came from and how it was checked. If it can't be supported, it doesn't go in. If an action can't be verified, the system shouldn't be claiming it worked.

2. A human confirms the things you can't undo

AI can research, analyse, prepare and recommend. Sending, publishing, moving money and changing access are a different category — those get a deliberate yes from a person. Automation shouldn't remove the human at all costs. It should free the human up for the part where their judgement is genuinely worth something.

3. Boundaries before capabilities

If a system touches sensitive data, money or real decisions, safety can't be a filter bolted on at the end. First decide what the AI must not do. Then build what it may do.

4. Measure the outcome, not the process

"Feels better" isn't a metric. I've lost count of the times the tests were green and the product was still broken. So I try to measure the end result, not whether the pipeline ran to the end. With AI this matters more than usual, because a well-written wrong answer reads like a right one.

5. Every mistake should leave the system better

I'm not interested in AI that supposedly never gets things wrong. I'm interested in systems that improve because someone caught it. When something goes wrong I ask: what rule or check would have caught this? Over time those answers turn into tools and checks that get reused.

Why OEJ?

There's more than ten years of software, data and technical operations behind me. What AI actually changed is how large a system one person can build and keep running. One old principle didn't change: a bad process with AI on top is just a faster bad process.

That's what OEJ is for: finding where AI genuinely pays off in a business, then building the system around it so the result stays verifiable, secure and useful long after the first impressive demo has worn off.

I don't sell AI. I build ways of working where AI carries the part it's actually good at — and where you can still see what it did, what it based that on, and when not to trust it.

Contact

Let us talk about your first workflow

Write to info@oej.ee or register your interest via the contact form.

Register your interest