AI put to work. People who decide.
Start with your existing tools and one task worth improving. Agree the result, configure or build what is needed, test it with the team, and leave clear instructions for running it.
Start where you are
A useful engagement meets the work, the people, and the tools you already have. Sometimes that means helping a team get real use out of the assistant it already pays for. Sometimes it means rebuilding a back-office process. We start with what you have. If a configuration change solves the problem, we won’t propose a custom build. And we do not drop a long recommendation and leave you to implement it.
Change the shared job
An assistant can help someone draft, search, or check their work. For a task shared across a team, we also look at intake, the information people need, and who takes the next step. Better setup and training may be enough; connected workflows or a custom agent are options when the task needs them.
You own the first and last mile
You choose the job worth doing and the standard it has to meet. AI can research, draft, route, and check the middle. A person still sets direction and still reviews what matters before anything is sent, filed, or paid. Preparing a reply is not sending it.
Write it so it keeps working
Agents are fast. Long runs drift. The durable part of the work is the written instructions, examples, and checks that keep the next session on the rails. Code can be regenerated. The “why” and the operating rules cannot.
Show something real early
Put a first working version in front of its users. Their feedback helps decide what to build next. Agree timing around that scope.
One workflow.
A scope you can evaluate.
A pilot should answer a business question. Agree the task, the evidence, and the decision before expanding the build.
- 01
Choose one workflow and look at what you already have
Identify the task, its owner, its inputs, and the output someone actually needs. We check the AI licenses, software, and data access already in place, because a setting or a better routine sometimes removes the problem without a build.
- 02
Agree what an acceptable result is
Write down what must be correct, what may stay uncertain, and what has to stop the workflow. Choose the ordinary examples and the awkward ones it will be judged on, and name the person whose acceptance counts.
- 03
Implement, verify, and train the people who use it
Configure or build the agreed scope, then run it against those cases and record the failures as well as the passes. The team practices on its own work, including the exceptions and the point where a person has to decide.
- 04
Hand it over — support only if you want it
Review the evidence and the remaining limits with the workflow owner, then decide whether to launch, revise, or stop. You receive the operating record, access, and recovery steps. Continuing support is a separate choice, not an assumption.
Start with a one-page brief
A useful outline names the work, the owner, and the result worth testing. Download an editable Markdown template, or use the questions below in your own document.
Free to download. No email required. Keep credentials and confidential records out of an initial brief.
Download the project brief (.md)- The job
- What starts the task, who does it today, and where it gets stuck?
- The boundary
- Which systems may it read or change, and what needs approval?
- The result
- What would count as useful, who checks it, and when should it stop?
Before we begin.
Is this just ChatGPT for the team?
It can start with helping people use ChatGPT or another assistant well. If the task crosses a team, we also examine shared sources, handoffs, and approvals. We agree whether setup and training are enough or a connected workflow is needed.
Do you replace the people who know the work?
No. They choose the job and they review what matters. AI prepares the middle. If a task should not be automated, we say so.
What do we have to write down?
Enough that the next run knows the goal, the sources, the checks, and when to stop. That operating record is part of the handoff, not an extra slide deck.
How do you work with our internal IT team?
They stay in charge of your systems. We ask IT which accounts, licenses, and integrations exist, agree the least privilege a workflow needs, and route access requests through their normal process rather than around it. Where your team prefers to own the build, we can scope the design, the acceptance tests, and the review instead. Whatever we hand over comes with the operating record IT needs to run or change it.
What makes a good first AI or automation project?
Choose a repeated task with accessible examples, a clear output, and someone who can judge the result. Define its beginning and end, the tools involved, and the exceptions that need a person. That makes it possible to agree acceptance criteria and assess the work before expanding it.
How much does an AI or automation project cost?
Price depends on the workflow, source quality, integrations, permissions, and review requirements. A scoped proposal should separate implementation from recurring model, hosting, platform, and support costs. Describe one task first so the estimate can be based on the work and its dependencies.
How long will the project take?
The timeline is agreed for the specific scope. Access to systems, ready source material, unresolved business rules, and the availability of reviewers all affect delivery. The project plan should identify those dependencies and distinguish a feasibility prototype from a workflow ready for everyday operation.
Can we use the software and data we already have?
Assess the existing tools and sources first. APIs, exports, account permissions, data quality, and provider terms determine what can be connected. Begin with an outline or redacted examples; agree a suitable sharing method before providing credentials or sensitive records.
How will we know whether the result is good enough?
Agree test cases and acceptance criteria with the person who owns the workflow. Check expected outputs, evidence, incomplete inputs, and permission boundaries. Review the recorded failures as well as successful runs, then define the monitoring needed for the initial rollout.
Who owns and maintains the result?
Code ownership, licensing, hosting, access, and continuing support are terms to agree before work starts. The handoff should identify the owner for source updates, failures, credentials, and changes. Continuing maintenance is part of the engagement only when it is explicitly included.