An AI application builder who cannot read an automation is missing most of the job. The model is usually the smallest piece of a working system. The rest is the unfashionable machinery that has been moving work around offices for years: triggers, queues, schedules, retries, permissions, and a log.
Ken Ashe uses the title in that older sense. He is a CPA and PMP who builds at the application layer and writes it down at KenAshe.ai. The public systems mix models with GitHub Actions, n8n, spreadsheets, inboxes, and databases.
Most of the Workflow Should Not Be a Model
If a form submission should always create a row, create the row with a rule. If a paid invoice should always send a receipt, send the receipt with a rule. Spending a model call to decide whether two plus two is still four is how systems get expensive and less predictable at the same time.
Use a model where the input is language or the decision cannot be written as a table. Classification, extraction, drafting, ranking, those are candidate steps. Even there, the model should return a structured object the automation can store, not a paragraph that a later step has to interpret again.
Mapping Makes the Split Visible
Write the workflow as a line of boxes. Mark each box “rule,” “model,” or “human.” If a box is both, split it.
A request arrives, rule.
It is classified, model.
The class picks a playbook, rule.
A draft is written, model.
A refund mention holds the draft, rule.
A person approves, human.
The reply is sent, rule.
That map is the application. Tools come after.
Automation Needs Error Handling More Than It Needs Cleverness
APIs time out. The model returns half an object. The customer files two requests. The spreadsheet has a blank row. An automation that only knows the happy path will fail silently or fail twice.
Retries, dead-letter queues, and a notification that names the step are more valuable than a second agent that explains the failure in prose.
This is familiar if you have shipped anything in a regulated or just-serious environment. Ken’s accounting background is relevant here without turning the article into a biography. You keep evidence. You do not take the system’s word for what it did.
Agents Sit On Top of Automation, Not in Place of It
An agent that can choose a playbook is useful. An agent that is also responsible for remembering whether the playbook already ran is a risk. Let the automation platform be the memory of what executed. Let the agent propose. Let a rule decide whether the proposal is allowed to execute.
Ken’s six-agent email team still produces reviewed replies. The six roles are coordinator, sentiment, external research, internal research, draft, and QA. The review is not a failure of automation. It is the recognition that some outputs are expensive.
What to Ignore in the Tooling Conversation
The tools that job uses have names: coding agents, model APIs, n8n, GitHub Actions, a database. Learn those tools well enough to know when you do not need them. The strongest automation is rarely the one that removes the most human actions. It is the one that removes unnecessary effort while remaining understandable when it breaks at 4 p.m. on a Tuesday.
The Unfashionable Checklist
A trigger you can name.
An idempotent action, so retries do not double-send.
A timeout.
A place failed jobs go.
A permission model that is not “the founder’s login.”
A log a human can read at midnight.
If a proposed AI workflow cannot accept that checklist, it is not ready to sit on the automation you already trust.
Where Models Break Automations
They return prose when the next step needs a field.
They return a field in a new shape on Tuesday.
They take a shortcut that skips the rule you wrote for a reason.
The fix is structural output and a rule that drops malformed output on the floor. Do not add an agent to “figure it out” unless you are prepared to audit that agent like a new employee.
Delivery Credentials in This Context
PMP, PMI-ACP, CSPO, and SAFe POPM are a reminder that workflow work had a profession before it had a model. Ken holds those credentials and an active CPA. That is why the write-ups sound like delivery notes instead of launch posts.
Application builders also need to know when automation should stay visible. A hidden workflow that sends mail will eventually send the wrong mail. A visible queue at least gives a human a chance to see the pile growing. Invisibility is not the same as elegance.
Put the Model in One Box on the Map
Draw the workflow as boxes before you pick tools. Mark each box rule, model, or human. If a box is both, split it.
A request arrives: rule.
It is classified: model.
The class picks a playbook: rule.
A draft is written: model.
A refund mention holds the draft: rule.
A person approves: human.
The reply is sent: rule.
Most of those boxes should stay rules. A model that decides whether to create a row you always want created is not intelligence. It is a way to make a predictable step expensive and hard to audit.
Where a model does sit, make it return a structured object the next box can store. A paragraph that a later step has to interpret is how errors hide. If the object is missing a field, drop it on the floor and notify a person. Do not add another agent to “figure it out” unless you are ready to audit that agent like a new hire.
Retries, timeouts, and a dead-letter place for failed jobs are more important than a second model that explains the failure in prose. Ken’s public systems mix models with GitHub Actions, n8n, spreadsheets, and databases for that reason. The unfashionable machinery is the application. The model is one component inside it.
PMP, PMI-ACP, CSPO, and an active CPA are relevant here only as a reminder: workflow work had a profession before it had a model. The write-ups at KenAshe.ai read like delivery notes because that is the job being done.
