I was tired of waiting.
I hired two AI experts and four programmers because I wanted to bring automation into my company. Two years later, I still did not have the automation I had been waiting for.
I let the team go. I told my son we needed to do this ourselves.
That is how I remember the turning point. It was a decision to take responsibility for getting the work done. We would have to learn things we did not know yet.
The people who make it happen.
My son and I took on the challenge. Mike is part of this journey, and so is José Alejandro.
José Alejandro is a key player. He will do anything, anytime—from hardware to software. When you are trying to build something, that willingness matters. There is always another problem to work through, and the work does not stay neatly inside one job description.
I want him to have a real place in this story. The projects matter, but so do the people willing to do what it takes to move them forward.
How do you install Linux?
There is a moment I want to go back and find in Mike’s ChatGPT history. He asked how to install Linux on a server we had sitting around the office. I remember it being in September.
I like that as part of our story because it is such a basic, practical starting point. We had a server. We had something we wanted to do. First, we needed to learn how to get it running.
I still need the original conversation to put the exact date on it. I would rather leave that open than make the history sound more certain than it is.
The work started taking shape.
Looking back through our messages and project records, I can see the questions becoming more specific. Can we stop doing this test by hand? Can we find the information already inside the company? Can we tell who is responsible for following up?
The records also keep me honest about the sequence. A September email reports an automated bandwidth test running at the end of August. I still need to place that against the earlier team change. I do not want to lose credit for work that happened along the way just to make the story simpler.
Start with something useful.
Bandwidth testing was one practical example. I wanted it running without someone having to do every step by hand. A delivery email reported an unattended run. That is a useful piece of the history, even while we check the full sequence.
Give the work a place to run.
The messages turn to a Linux server for collecting information. Mike’s remembered installation question belongs somewhere in this early chapter; its exact place is still open.
Connect the pieces.
Company knowledge, customer conversations, billing checks, and request routing became concrete projects. Some tools were implemented. Other parts were still being designed or tested.
Find out where it breaks.
New tests found things the router missed. A local AI model produced answers that sounded convincing but went beyond the evidence. Those findings gave us more work to do before letting people depend on the results.
What I actually want from AI.
I want it to do useful work in the company. Find an answer without searching through one conversation after another. Make it easier to see what needs attention. Help us follow through on what we told a customer we would do.
That sounds straightforward until you start putting it together. The information can disagree. A customer can ask the same thing in several different ways. A system can say a task is closed while the person at the other end is still waiting.
Those are the problems behind the projects.
The problems
that became projects.
Who is taking care of the customer?
There can be a chat, an email, an assigned name, and a promised update. I want to know who has actually taken responsibility and what happens next.
We built a dashboard to bring those pieces together. It helps us review the conversation, keep track of commitments, and prepare a follow-up with the context in front of us.
One distinction matters to me: putting someone’s name on a case does not mean they have accepted it. Closing a ticket does not prove the customer’s problem is solved. The tool helps us see the work; people still have to follow through.
The service and the bill should tell the same story.
We worked on an auditor to compare service status with recurring billing. If those records disagree, we need to understand why.
We also had to learn when to leave something alone. A paused subscription does not always mean the same thing. A similar account name is not enough to make a change.
The project grew into a monitor with tightly limited corrections and checks afterward. Some reviewed contracts were reopened with approval. Other cases stayed with people because the evidence was not clear enough. I want the automation to save work without creating a new problem for the customer.
We already knew more than we could easily find.
American Data has information spread across emails, customer records, services, network records, and work orders. We started bringing those sources together in Brain so they could be searched.
By late October, a saved report showed eight populated indexes, including more than two million email records. That was a concrete step forward: we had a much larger body of company information available to search.
It was not the finish line. Missing records still had to be investigated. Access needed checking. Conflicting information still needed a decision about which source to trust. Collecting the information gave us a foundation to keep building on.
Our customers speak like our customers.
People do not write to support using the labels inside our systems. They use local expressions, make spelling mistakes, and switch between Spanish and English.
We put together a Costa Rican slang dictionary for the router. The idea was to help it recognize what people mean in the way they actually speak.
That dictionary is built, but it still needs local review and testing before we rely on it. Understanding an expression should help us ask a better question. It should not give a system permission to change a bill or decide an outage has been confirmed.
We had to ask questions it had not practiced.
A router can look good on the examples we have already been using. I wanted to know what would happen with different wording.
A fresh test set exposed requests it misunderstood, including local language and questions that needed clarification. The familiar tests were passing, but the new ones showed gaps.
That is useful progress too. It tells us where to work next. We still need broader testing and human review before treating those results as proof that it is ready for everyday use.
Fast answers are not enough.
We tested a local AI model against real email passages. Could it turn what we found into an answer, while the existing search and email processing kept running?
It answered quickly. But when the answers were compared with the original passages, some added facts the source did not support. A citation could be present and the answer could still be wrong.
A more restricted version checked exact quotations and rejected one that had been changed. We also found that generating answers slowed the search more than our test plan allowed.
So that pilot was not ready for staff. We had built something we could test, and the test showed us what still needed fixing. I would rather know that now than put a confident wrong answer in front of someone who trusts it.
We are still building.
I do not want this page to pretend we have finished everything. We have tools, tests, and working pieces. We also have gaps, mistakes to fix, and decisions that still need a person.
What changed was that we took the work into our own hands. We started asking the basic questions, looking at the results, and deciding what to try next.
That is the journey I want to share here. The people, the projects, and what we learn as we keep going.