The problem was between the tools
When we explored how AI could support operations at Throughout, my first instinct was to think about models, agents, and automation tools. The underlying difficulty was more ordinary: information was spread across systems, and people had to connect it manually.
Sales lived in one platform. Our CRM held employee records, attendance, payroll, projects, invoices, and expenses. Engineering activity came from Jira and GitHub, while a KPI dashboard provided another view of performance. Each system had a purpose, but an end-to-end process still crossed several of them.
Map the handoff before choosing the automation
Consider preparing an invoice after a project milestone. A workflow needs evidence that the milestone is complete and enough context to prepare the right draft. Or consider delivery planning: deadlines are less useful without budget and team-availability context.
The first step is to describe what information is needed, which system owns it, and who checks the result. Without that map, an AI layer can produce another place to look rather than reduce the work between existing tools.
Give each workflow a bounded responsibility
Our design explores specialised workflows for sales, HR, finance, and operations. They can prepare lead information, reconcile records, flag exceptions, draft invoices, or surface delivery and capacity risks.
The distinction I care about is preparation versus commitment. Preparing a reviewable draft is different from sending it. Highlighting an inconsistency is different from deciding what someone should be paid. The workflow should make the evidence and proposed next step understandable to the person responsible.
Keep decisions with accountable people
In the source post, I described a boundary around salaries, employment, payments, taxes, clients, and major commitments. AI can perform routine checks and prepare recommendations; people remain responsible for decisions in those areas.
A useful design question is what happens when the available data is incomplete or contradictory. Instead of forcing the automation to complete every case, provide a path for review. The system should expose uncertainty rather than make it harder to notice.
Separate design targets from achieved results
Our stated design target is 80% of routine administrative preparation automated, 15% managed through simple approvals, and 5% escalated for professional judgement. These are planning targets from the post, not measured results or a promise for another business.
An earlier reflection described substantial internal automation more broadly. I would not combine that statement with these targets into a quantified case study without a defined measurement period and method. For a new workflow, first decide what work is being counted and what a successful outcome means.
Begin with one recurring source of delay
Choose a process that repeatedly requires someone to collect the same information. Map its inputs and decisions, define the human review point, and implement a small workflow that prepares the next step.
What matters is whether the process becomes easier to understand and run. The lesson from our design work is that operational AI starts with process clarity, connected information, and clear responsibility—not with the choice of the smartest model.
What to take away
- Connect the necessary data before adding another interface.
- Give AI bounded preparation tasks and clear review points.
- Label targets as targets until measured results exist.