Notes on practical AI.

"AI agent" and "automation" get used almost interchangeably in vendor pitches, which makes it hard to know what you're actually buying. The distinction matters, because it changes how much oversight a system needs and where it's appropriate to use.

Automation follows a fixed path

Automation, in the traditional sense, executes a defined sequence: if this happens, do that. It's reliable specifically because it's predictable — the same input reliably produces the same output. Modern automation pipelines often include an AI-powered step (reading a document, classifying an email) inside an otherwise fixed sequence.

Agents make a decision about what to do next

An agent, by contrast, is given a goal and some tools, and it decides the sequence of steps itself based on what it finds. That flexibility is useful for tasks that don't follow the same path every time — but it also means an agent's behavior is less predictable than a fixed pipeline, which is exactly why scoping its permissions and adding approval checkpoints matters.

Which one do you actually need?

• If the steps are always the same regardless of the input, that's automation — simpler to build, easier to trust.
• If the right next step depends on judgment about what was just found, that's agent territory — more flexible, but it needs clearer boundaries.
• Most real systems are a mix: an automated pipeline with an agent handling the one step that requires judgment.

The practical takeaway: don't reach for an agent because it sounds more advanced. Reach for whichever gets the job done with the least unpredictability required.

Teams often start an AI initiative by picking the most impressive-sounding use case — usually something customer-facing and highly visible. That's often the wrong place to start.

Start with something bounded and measurable

A good first project has three properties: a clearly defined scope, an existing way to measure success, and a fallback if the AI-driven step gets something wrong. Internal, lower-stakes workflows — an inbox triage step, a document-classification task — usually qualify. Customer-facing systems can come later, once you've built confidence and a track record.

Decide what "good enough" looks like before you build

It's tempting to iterate on a system indefinitely, chasing a slightly better result. Decide up front what threshold of accuracy or reliability would make the system worth deploying, and what happens to cases that fall short of it — usually, routing them to a person rather than guessing.

Plan for the exception path, not just the happy path

Most of the actual engineering effort in AI integration goes into handling the cases that don't fit the pattern — malformed documents, ambiguous requests, systems that are temporarily unavailable. A system that handles 80% of cases well and clearly flags the other 20% is usually more useful than one that tries to force an answer every time.

Then, and only then, integrate

Once a step is proven on its own, connecting it into your existing systems (CRM, inbox, database) is usually the more mechanical part of the work — which is also why it's worth doing last, not first.