After 25 years in tech from telecom networks to AI agents, only three lessons actually mattered. Here's what they are.
I started in tech in 2001. A junior network engineer at a telecom company in Algeria. The internet was dial-up. Mobile meant SMS. Cloud computing did not exist yet.
Twenty-five years later, I run two companies, manage a team of AI agents, and build systems that would have sounded like science fiction to my 22-year-old self.
Most of what I learned in those 25 years is obsolete. The specific technologies, the vendor certifications, the protocols and standards. All replaced by newer versions or gone entirely.
But three things stuck. Three principles that were true in 2001 and are still true today, regardless of what the technology stack looks like.
My first big project was rolling out a GSM network across a region. The technical team was brilliant. The project management was chaos. No standard processes. No documentation. No repeatable workflows. Every decision was made fresh, from scratch, every time.
We delivered late. Over budget. The output worked, but the path to getting there was painful.
A year later, a different team with less raw talent delivered a similar project on time and under budget. The difference was not the people. It was the system. They had playbooks. Checklists. Handoff protocols. Status reporting cadences.
I have seen this pattern repeat for 25 years across every domain I have worked in.
A mediocre team with good systems will outperform a brilliant team with no systems. Every time. The systems remove the dependency on individual heroics. They make the average output reliable, which matters more than the occasional peak.
This is why I built Ayla OS the way I did. Not to replace brilliant people, but to create systems that make consistent output the default. My agents follow defined processes. They have standard interfaces. They report status in predictable formats. The system does the heavy lifting of coordination so the humans can focus on judgment.
The exact architecture, memory layers, and delegation patterns I use to run 50 agents across two businesses.
Get the AI Agent Blueprint →In 2005, I spent three months building an elaborate network monitoring dashboard. Beautiful interface. Real-time metrics. Custom visualizations. I was proud of it.
Nobody used it.
The network operations team needed alerts when something broke. They did not need a dashboard. They needed a pager that buzzed at 3 AM and told them what was down. The simplest possible solution to the actual problem.
I had built an impressive solution to a problem nobody had.
This lesson took me embarrassingly long to fully internalize. Even now, I catch myself reaching for the elegant technical solution when a simple one would do. The pull toward complexity is strong when you love building things.
In my consulting work at Allwebzone, the first question is always: what problem does this solve, and for whom? If the client cannot answer that clearly, we do not build anything. We help them figure out the problem first.
The AI agents I build for businesses are not impressive because of their architecture. They are useful because they solve real problems. An agent that saves someone 10 hours per week on email triage is more valuable than a sophisticated multi-agent system that produces a report nobody reads.
In my telecom career, I rose to Deputy Director. The higher I got, the more requests came in. Every department wanted resources. Every initiative was “high priority.” Every deadline was urgent.
The teams that shipped on time were not the ones that said yes to everything. They were the ones that said no to almost everything and focused completely on the few things that actually moved the needle.
I carry this into how I run my businesses today. Digital Fennec does not serve every type of client. We specialize. Allwebzone does not offer every type of AI service. We focus on what we are best at.
My AI system reflects this same principle. Every agent has a narrow scope. It does one thing well. The orchestrator says no constantly: this task does not match any agent’s scope, so it escalates to me for a decision rather than trying to force-fit it somewhere.
The temptation in AI is to build agents that do everything. General-purpose assistants that handle any request. In my experience, those agents produce mediocre output across the board. Specialized agents with clear boundaries produce excellent output within their domain.
Saying no is not about being rigid. It is about being honest regarding where you create the most value and concentrating there.
The technology changed completely. In 2001, I configured Cisco routers with command-line interfaces. In 2026, I configure AI agents with natural language prompts. The specific skills are different.
But the meta-skills are identical. Build systems. Solve real problems. Focus relentlessly.
If you are early in your career, invest in these three things. The specific technologies you learn will be obsolete in five to ten years. The principles will carry you for 25 and counting.
If you are deep into your career and considering a pivot (like I did from telecom to AI), know that your hard-won principles transfer. The domain changes. The fundamentals do not.
I write about these intersections between career experience and AI building in the newsletter. Not theory, but patterns I have seen play out over decades.
Twenty-five years is a long time. Most of it blurs together. But these three lessons are as clear today as the day I learned them.
Subscribe to The Signal
One issue per week. The biggest AI build of the week, the top five videos worth your time, and an operator's read on what actually matters. For builders who ship, not dreamers who scroll.
No spam. Unsubscribe anytime. Just The Signal.