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](https://www.uber.com/) in
Kraków, then at [Kahoot!](https://kahoot.com/), I saw the work customers did not
see: tracking updates, refunds, invoice adjustments, spreadsheets, and small
pieces of context disappearing into [Slack](https://slack.com/) 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](https://www.gelato.com/), I began turning those observations into
systems. I started with [Make](https://www.make.com/), automating support
escalations from [Zendesk](https://www.zendesk.com/) into
[Jira](https://www.atlassian.com/software/jira). Later I worked across
[n8n](https://n8n.io/), [HubSpot](https://www.hubspot.com/),
[Intercom](https://www.intercom.com/), and [Slack](https://slack.com/).

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](https://fin.ai/) inside
[Intercom Messenger](https://www.intercom.com/messenger), 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](/notes/automating-order-status-for-print-on-demand).
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](/#contact)
and tell me where the current hand-off breaks.