Start at the client’s desk, before opening the model catalogue
An embedded approach finds the real work, its exceptions and the people who must trust the result.
The most useful place to begin an AI project is often beside the person doing the work. Watch a task move between an inbox, a spreadsheet, a business application and a conversation with a colleague. Ask where it slows down. Ask what happens when the normal process breaks.
This is the forward-deployed style of engineering I want to bring to clients: stay close enough to understand the operational problem, then take responsibility for translating it into a working system. It combines discovery, architecture, implementation and adoption in one continuous conversation.
Observe the work as it happens
A workshop might describe the process as “prepare a project update.” At the desk, someone is resolving conflicting task statuses, chasing an owner, deciding which delay matters, and rewriting the update for different audiences. Generating a paragraph solves only a small part of that job.
I would begin with a concrete work sample and trace it from request to completion. Which information was available? Which judgement required experience? Which systems were touched? What made the result acceptable? What happened to the exception that nobody put in the process diagram?
Then I separate the steps. Some need a better form or integration. Some are deterministic transformations. Some benefit from retrieval or language understanding. Only a few may require an agent to decide what to do next. This avoids putting model calls into steps that ordinary software can already handle clearly.
Define the first useful outcome
The first useful deliverable is a shared problem definition: who owns the work, what outcome matters, the current baseline, the permitted data, and the cost of getting it wrong. That gives the team a way to judge a pilot beyond whether the demonstration looks impressive.
For an illustrative project-update assistant, I might start with read-only access, a draft grounded in linked task records, visible unresolved questions and a manager’s approval before circulation. The pilot would measure time to an accepted update, missing facts, correction effort and usage. This is a proposed pattern, not a claim about a named client deployment.
Make adoption part of delivery
Working alongside people also reveals adoption constraints. An elegant separate application may create another place to check. A smaller change inside the existing workflow may be more useful. The right delivery includes training, ownership, a support route and a way to recover when the system is unavailable.
I bring software delivery, IT leadership and product experience to that conversation. My role is to connect business pain with the architecture and engineering needed to change it. I want a client to leave with a working capability and people who can operate it, with a clear handover that lets the team continue improving it.
For discovery and delivery alongside your team, explore Embedded AI Delivery at fdo.codes.
