How we work
Build with the people who know the work. Give AI a useful part of it.
The first goal is not to persuade everyone to adopt AI. It is to work with employees on something the company already cares about and make a better way of doing it real.
Bring the hunch and the people who know the work.
A useful first conversation begins with something you think AI might change. You do not need a prescribed solution. We do need access to the employees, data, systems, and examples that reveal how the job actually works.
Learn the job before assigning any of it to AI.
I trace the current work with the team, reproduce the calculations, inspect the evidence, and look for exceptions. The goal is not to automate a description of the process. It is to understand the responsibility well enough to redesign it.
Give AI a useful, bounded part of the work.
Some steps should be deterministic software. AI can handle appropriate ambiguity, drafting, matching, and investigation. Employees keep the context, judgment, and accountability that belong with them. Uncertain work returns to the right person instead of being hidden.
Build the surrounding system and use it for real.
An agent needs evidence, tools, rules, tests, a place in the workflow, and a path for exceptions. Real use exposes bad connections, missing records, changed names, confusing states, and assumptions nobody had written down. We keep iterating, or choose a better answer.
Keep the work client-owned and give it a responsible operator.
Client-specific code, data, infrastructure, rules, tests, and documentation stay with the client. That makes the work transferable, not self-running. Botworks operates it while engaged; a future handoff requires a named person or partner who can direct agents, review consequential changes, and remain accountable for production.
Why the work comes first
People need a reason to change how they work.
An executive may believe AI could help while having no reason to ask employees to change their habits for a promise. A working result gives the team evidence from its own business and a chance to shape the system around what it knows.
When AI does something that was difficult before, broader use stops feeling theoretical. Training, guardrails, and documentation now support work people already understand and value.
Do not make employees work for the AI. Build AI that works with them.
The commercial relationship
Usually a retainer. Never artificial lock-in.
Ongoing work commonly runs through a monthly retainer because production systems and recurring analysis need continuity and an accountable operator. The fee is for the work Botworks is doing, not a license claim on the client’s future.
The client owns what we build. Ownership does not mean every employee should use agents to change production code, or that software will safely improve itself after Botworks leaves. If responsibility moves, the handoff should be deliberate and made to someone prepared to own it.
What Botworks takes responsibility for
- •If software is live, it works for the problem and the people it was built to serve.
- •If the work is analysis, the sources, definitions, assumptions, and disagreements remain inspectable.
- •AI uncertainty, real exceptions, and failures are visible to the person equipped to decide what happens next.
- •The company can see what is validated, what is experimental, and what remains open.
What gets built
Purpose-built software, without turning every workflow into a new product.
Most Botworks engagements involve custom software: SQL, data connections, processing scripts, document generation, agents, monitoring, or focused internal interfaces. The boundary is not custom versus off-the-shelf. It is whether the business needs a company-specific operating system or an unnecessary attempt to recreate a mature SaaS product.
Use the good product. Build the company-specific software, connections, and intelligence around it.
Start with the rough problem.
You do not need to decide whether this is AI, software, data, or operations work before getting in touch.