Most internal AI rollouts I see die the same quiet death. Someone wires up a chatbot, a few people try it, the answers are decent, and six weeks later the tab is closed and nobody misses it. The model was fine. The integration point was wrong.
I'm Justin Pennington, founder of Infraxio, based in Ponte Vedra in St. Johns County, Florida. We build operations software for mid-size businesses, and we run our own company on it. This is a developer-oriented rewrite of a longer essay on my site, Put AI on the Task Board, Not in a Chat Window. More about me and what we build: infraxio.com/justin-pennington.
The short version: if you're building AI into an operational tool, stop modeling the agent as a conversation and start modeling it as a user who can be assigned work.
We've shipped this bug before
Anyone who has implemented a CRM has watched this movie. The CRM was a place you had to go to, not a place where the work already lived. Reps kept their real pipeline in a spreadsheet, the CRM became a reporting surface for management, and adoption numbers looked great right up until someone checked the data.
Bolt-on AI chat has the same architecture problem. It's a side trip. Side trips don't survive a busy Tuesday.
People don't abandon tools because the tools are bad. They abandon tools that aren't on the path of least resistance. In most companies, that path is the system of record: the board or tracker where tasks get assigned, statuses change, and work gets reviewed.
Chat is the wrong primitive for operational work
Chat is great for brainstorming, ad-hoc questions, and first drafts. But look at what a chat session lacks compared to a task:
| Property | Chat session | Task |
|---|---|---|
| Owner | None | Assignee |
| Deadline | None | Due date |
| State | Scrollback | Status column |
| Review | Optional, manual | Built into the workflow |
| History | A transcript nobody searches | Activity log on the record |
| Downstream links | Copy-paste | Dependencies, parent project, client |
When operational work happens in chat, you've quietly created a parallel system. The real system of record never learns the work happened, and the decision it informed isn't recorded anywhere that matters.
The design: the agent is just another assignee
This is how we approached AI inside IFX Hub, our operations platform. A task can be handed to a person or to an AI agent, and the mechanics are deliberately identical:
- Assign the task, with the same fields any task has: description, due date, context.
- The agent picks it up and does the work.
- Status moves to review when it's done.
- A human approves it or sends it back with comments, exactly like reviewing a colleague's work.
If you're designing this yourself, the main implication is in your data model: the assignee field shouldn't care whether it points at a human or an agent. Same task table, same status machine, same comment thread, same permissions checks. No separate "AI results" screen.
That one decision buys you three things for free.
An audit trail. Every agent action is logged where human actions are logged. You don't need a separate dashboard to answer "what did the AI do, when, and who signed off?" The task history answers it.
Review by default. Agent output lands on the same board as everything else, so it enters the same review loop. The ops lead who scans the board every morning sees AI-completed and human-completed work side by side. There's no extra step to go check on the bot.
Accountability. When something goes wrong, and something always goes wrong, you can trace it: assigned at this time, produced this output, reviewed by this person, approved or rejected. That chain of custody matters for quality, for compliance, and for not losing track of what happened.
What to route to the agent first
Not every task belongs on an agent's queue. The filter we use internally, and with clients, is three questions. A task is a good first candidate only if it passes all three.
- Repetitive: it follows the same pattern every time. Status updates from structured data, a report from a template, background research for a bid response, a follow-up email triggered by a project milestone.
- Well-specified: you can check the output without senior judgment. The extraction captured the right fields or it didn't. The report matches the template or it doesn't.
- Reversible: if it's wrong, fixing it is cheap. A draft that needs editing is fine. Deleting records, sending a client communication, or submitting a bid should stay with a human until you have real confidence in that specific workflow.
Anything that's novel, ambiguous, and consequential stays with people: strategy, client relationships, calls that depend on context the system doesn't capture. The point is to take load off people so they can spend time on the work that actually needs them.
Build for the 7 AM Monday, not the demo
A natural-language query bar or a generative dashboard looks great in a demo. The features that survive are the ones that remove a step from a workflow the user is already doing. "Assign this to the agent" is one click on a board people already open every morning. "Open the AI tool and explain the context" is a new habit, and new habits lose.
That's the same lesson I've seen with clients across Jacksonville and Northeast Florida for years, whether the tool was an ERP, a CRM, or now an AI agent: the software has to live where the work happens, create less friction rather than more, and make it obvious what happens when you use it.
I'm curious how others are handling this. If you've put agents into a production workflow, did you model them as users, as background jobs, or as something else, and what broke?
Originally published on penningtonj.com. Justin Pennington is the founder of Infraxio in Ponte Vedra, Florida.
Top comments (0)