Before I add AI, I want to see the workflow

People fell in love with ChatGPT, and I understand why. For the first time, you can drop a messy thought into a conversation window and get back an answer, a plan, an analysis, or a usable draft. After that experience, it is very easy to take the next step in your head: if AI can respond this well, maybe we should give it more. Let it think for us. Let it take over the process. Let it make the decision.

I understand that temptation because I feel it too. While building my own applications and working through implementation ideas, I increasingly notice the same pattern in myself: before I start imagining a model moving through the entire process from A to Z, I need to step back and ask what the work looks like before automation touches it.

I do not mean the clean version from a presentation, where the process moves neatly from one box to another. I mean the actual workflow: who receives the first document, who corrects it, where the email appears with "this still needs to be checked", which spreadsheet is the source of truth even though nobody wants to admit it, who makes the decision, and who only prepares material for somebody else.

Only then can I ask whether AI belongs there at all. That is the part of this learning curve that feels most important to me right now, because I am starting to see that the skill I am building is not simply "using AI". It is understanding work well enough to choose the smallest safe intervention.

The smallest safe intervention

That phrase has become useful for me because it slows down my instinct to build the impressive version first. If a process has stable rules and stable inputs, normal software is often better than an agent. It is cheaper, easier to debug, more predictable, and usually less theatrical.

If the inputs are messy, people work across documents, emails, spreadsheets, and natural language, and the system needs to use several tools along the way, then an agent starts to make more sense. If the process involves responsibility, legal risk, taste, interpretation, or domain judgment, a human should probably remain in the loop, even if the system can produce a convincing demo.

This is less exciting than saying that we are going to deploy AI agents across the company. But the more I work with these systems, the more I trust these quieter distinctions. They protect us from treating technology as the answer before anyone has understood the question.

A weekly project report is a good ordinary example. If the same people fill in the same fields every week, with the same statuses and the same rhythm, then an autonomous agent is probably the wrong starting point. A form, validation, permissions, reminders, and a small script might solve the problem better.

That lesson matters to me because I naturally enjoy the more interesting tool. An agent is more fun to build than a form. But a good system does not need to be interesting for the person building it. It needs to fit the work it supports.

I am cautious by default

My default reference point is still architecture, because that is where I come from and how I learned to think about many complex problems. Imagine an investor asking what can be built on a specific plot of land. At demo level, this sounds like a perfect AI problem. NVIDIA's presentation showed what that future can look like in an ideal world: a person selects a site, provides sketches, a moodboard, and design intent, and the agent moves through the design tools.

You upload the zoning plan, planning conditions, plot parameters, and a few wishes from the investor. The system replies with the possible floor area, height, number of storeys, parking requirements, and biologically active surface. As a demo, it would look clean and useful.

But real architectural work is not a form with one final answer. You deal with planning language that can be precise in one paragraph and strangely soft in another. You deal with distances from boundaries, access, parking, roof geometry, building intensity, service functions, exceptions, local interpretations, and sometimes a conversation with someone who knows how things usually pass in that municipality.

AI can help a lot in that situation. It can read documents faster than a person, extract constraints, quote paragraphs, build a risk checklist, and show where the investor's ambition conflicts with the plan. It can prepare better material for the architect.

But it should not pretend to be the architect with the stamp. Responsibility does not disappear because the answer came from a model. Someone signs the project, someone owns the interpretation, and someone carries the risk that the decision was reasonable.

That is more interesting to me than the demo itself. A well placed system does not need to make the final decision. It can reduce friction, catch missed details, and show the human where to stop and think.

An agent is not a reward for complexity

For a while, I had the reflex that if a process was complex, it probably needed an agent. I believe that less and less now, because a complex process often needs order before it needs autonomy. It may need one source of truth, better statuses, a simpler form, smarter validation, or a clear answer to who is responsible for what.

This comes back when I think about knowledge systems and assistants. On paper, the idea sounds simple: we have documents, procedures, and users asking questions, so we build an assistant that answers. RAG, a chat interface, maybe a few tools, and it looks done.

In practice, the uncomfortable questions arrive quickly. Which procedure is current? Who approved it? Should the user receive a final answer, or only a suggestion? What happens if the system answers confidently using an old document? Where should it stop and say that a human needs to decide?

Those are not questions about whether the model "can handle it". They are workflow, responsibility, and source of truth questions. An agent only starts to make sense when I understand what it may do alone, what it may suggest, and what it must never touch.

In images, you also need to know what not to change

I see a similar lesson in architectural visualization work. From the outside, it is easy to describe the process simply: take an old render, run it through a system, and get something more attractive, more commercial, and more polished. That story is not wrong, but it hides the hardest part.

In practice, the most important thing is not only telling the system what to improve. The most important thing is telling it what it must not change. The building mass has to stay, the materials cannot randomly change the character of the project, and the facade divisions still need to make architectural sense.

The greenery can be better, the light can be better, and the atmosphere can feel more refined. But the architectural intent cannot collapse just because the system decided that "better" means more luxurious. That is where the work becomes judgment, not button pressing.

This is the difference between automation and responsible intervention. If a weak visualization needs to help sell a project, AI can be a powerful tool, but not as a magic aesthetics machine. It works better as part of a process where someone understands the design, controls the masks, compares versions, and notices when an attractive result starts to falsify the object.

In AI work, "better" does not always mean more impressive. Sometimes better means more faithful to what was already right. That small distinction matters to me because mature AI use often means constraining the system, not asking it to do more.

I am learning to understand work

When I look at this from the perspective of someone consulting on implementations and working close to real processes, I increasingly understand that the role is not about creating the most impressive demo in the room. It is closer to entering somebody else's mess and building something that survives contact with real work. That is much harder than it sounds.

Documents are incomplete. People have workarounds. Systems are old. Decisions are not always written down. Someone uses Excel because it is faster, while someone else carries important knowledge in their head because nobody ever turned it into a system.

This is where real AI implementation starts for me. Not with an imagined agent that does everything at once, but with understanding what we are actually trying to improve, who is responsible, where mistakes are cheap, and where mistakes are expensive. The technical layer matters, but it should not arrive before the work is understood.

If I were helping a company with AI inside an internal process today, I would not start with a list of tools. I would ask to see the work: documents, emails, spreadsheets, decisions, approvals, exceptions, the things that usually work but break once a week, and the places where people manually copy information from one system to another.

Only after that can we decide whether the right intervention is an agent, an assistant, a classic application, an integration, a checklist, or a better described process. That is less spectacular than saying "we build agents", but it feels much more honest. It also feels closer to the kind of builder I want to become.

Where should the system stop?

I am still building this muscle. I still get excited by the tool before I fully understand the problem, because the first moment when an agent completes several steps on its own really can look like magic. I do not want to pretend I am above that feeling.

But more and more often, after the first excitement, I come back to a simpler question. Not only what can this system do, but where should this system stop so that the human still has control, responsibility, and trust in the result?

That question feels more important to me with every project. If AI is going to enter real work, it is not enough for it to be fast and impressive. It has to sit inside a process that someone understands, can evaluate, and can stop at the right moment.

That is probably the main thing I am learning now. Not only how to use AI, but how to understand work well enough to know when AI helps, when it gets in the way, and when a boring piece of normal software is the better choice.