What frontline operations taught me about AI architecture

I did not learn AI architecture by starting with a model. I learned it by watching people keep real operations together with spreadsheets, chat messages, manual checks, and memory.

My goal here is to explain the working principles that came from that experience: how I find the real system behind a process, decide what technology is allowed to do, and make the result safe enough to become part of somebody’s Tuesday.

I learned the problem before I learned the stack

I started close to frontline operations. At Uber (opens in a new tab) in Kraków, then at Kahoot! (opens in a new tab), I saw the work customers did not see: tracking updates, refunds, invoice adjustments, spreadsheets, and small pieces of context disappearing into Slack (opens in a new tab) messages.

Neither role was about designing platforms. The job was to get the work done. That taught me three things:

• A process can look simple from the outside while asking a person to remember dozens of conditions every day.
• The person doing the work often knows more about the real system than the diagram does.
• Automation starts with ownership and exceptions, not with connecting two boxes.

I started automating the hand-offs

At Gelato (opens in a new tab), I began turning those observations into systems. I started with Make (opens in a new tab), automating support escalations from Zendesk (opens in a new tab) into Jira (opens in a new tab). Later I worked across n8n (opens in a new tab), HubSpot (opens in a new tab), Intercom (opens in a new tab), and Slack (opens in a new tab).

The stack became more capable, but the consequences of a bad decision became more real too. A workflow could move a ticket quickly and still expose the wrong context. An integration could work in a demo and still fail when a field was missing or a permission changed.

A process looks like	The architecture question underneath
“Move this ticket to that queue”	Who is allowed to see the context, and what happens when the destination is unavailable?
“Send this update automatically”	Which source is authoritative, and who owns the exception?

That is the part of automation I still find interesting: deciding what a connection is allowed to know, change, and do when the happy path ends.

The support problem that changed my model of AI

In one support environment, customers needed answers about orders, production, tracking, and technical issues. The context lived in several systems. The experience used Fin (opens in a new tab) inside Intercom Messenger (opens in a new tab), but the model did not need—and should not have—broad access to all of them.

The useful design was a narrow service behind the experience. It checked the merchant’s ownership of an order, assembled only the information that merchant was allowed to see, and gave the model a small, readable context. The AI had a modest job: explain the available facts. It was not asked to browse everything, invent an answer, or make an operational change.

Boundary	Deliberate limit
Read path	Check ownership and retrieve only permitted context
Model	Explain available facts rather than search every system
Action	Keep operational changes outside the model

That result became the order-status case study. The durable lesson was not “add AI to support.” It was that a model becomes more useful when the surrounding system is clear about what it cannot do.

The boundaries I look for first

When I design an operational AI system, I start with four questions:

1. Who is asking, and what do they own? Identity and resource ownership come before retrieval.
2. Is the task to explain, look something up, or change something? Each step adds a different level of responsibility.
3. What should the model see? Fetch and filter sensitive context first; give the model the smallest useful representation.
4. What happens when a dependency fails? A timeout, missing field, or contradictory record is part of the design, not an embarrassing exception.

The technology follows those answers. Sometimes the right solution is a workflow. Sometimes it is a secure internal tool or a custom connector. Sometimes the right answer is not to add AI at all.

How I work with a team

I am most useful when a process has become normal because nobody has had time to pull it apart. We start with the actual operating problem: where revenue leaks, where people repeat the same judgement, where a customer waits for context, or where a hand-off fails silently.

What I make explicit	Why it matters
Actors and domain objects	A system cannot enforce a boundary it has not named.
Ownership and decision rights	Knowing a record exists is not the same as being allowed to use it.
Allowed data and actions	A model should receive a bounded context, not a credential and a wish.
Success criteria and guardrails	Speed is not a win if quality, safety, or customer trust falls.

After launch, I look at inspectability and recovery. A workflow nobody can inspect is a future incident. A model that cannot explain which context it saw is hard to trust. A process with no recovery route is not automated; it is outsourced to luck.

Common questions

What kind of work do you take on?

I help teams turn operational knowledge into reliable workflows, internal tools, and bounded AI systems. Customer support, operations, and cross-system work are natural fits because the cost of missing context is easy to see.

How do you use AI in a client system?

I use it where language, classification, or summarisation genuinely helps. I keep deterministic rules, permissions, and consequential actions outside the model whenever possible. The model should have a clear job and a clear limit.

What makes a project a good fit?

You already own a real process or problem and want help making it easier to run, safer to scale, or less dependent on one person’s memory. A concrete, recurring pain is usually enough to begin.

The short version

• Start with the operating problem, not the model.
• Name the actors, ownership rules, and failure paths early.
• Give AI the smallest useful job and keep consequential control elsewhere.

If this is the kind of problem you are trying to solve, message me and tell me where the current hand-off breaks.