Beyond the Chatbot: How Enterprises Can Turn AI Into Useful Work

There is a widening gap in enterprise AI, and it is not the gap most people are talking about.

The models are improving quickly. The harder problem is adoption: helping real people inside real organizations understand what these systems can do, where they belong, and how to use them without giving up judgment or control.

In the first episode of Chasing the Signal, I sat down with Matthew Chenette, an AI Success Engineer who works with enterprise customers at a leading foundation lab. Our conversation kept returning to the same practical question: How do we move from asking AI for answers to trusting it with useful work?

The answer is not to chase every new model release or automate everything in sight. It is to change our relationship with the technology—carefully, experimentally, and with humans still responsible for the outcome.

Watch the episode

The capability gap is really an adoption gap

People who follow AI closely can forget how most people actually use it. Inside large organizations, many employees still treat a model as a better search box: ask a question, get an answer, move on.

That is useful. It is also only the surface.

Matthew described the central challenge of his work as bridging the gap between rapidly advancing capabilities and much slower adoption. The technology can already synthesize information from multiple sources, execute multi-step workflows, and take action through connected systems. Yet many potential users have never seen those capabilities applied to a problem they recognize.

That is why the most important moment in AI education is often not a technical explanation. It is the moment someone sees a task completed and asks, “If it can do that, can it do this?”

That question signals a change in perspective. Instead of wondering what they can ask the model, people begin to wonder what work they can delegate to it.

The word agent can make this sound more complicated than it is. Assistant may be the more useful frame. An assistant does not merely tell you how to schedule a meeting. It checks calendars, finds a room, prepares the invitation, and handles the steps around the task—within whatever permissions you have given it.

From “plus AI” to “AI plus”

Most organizations begin with what I call “plus AI.” They take an existing job or workflow and add AI to make one part of it faster. A developer gets help writing code. An analyst summarizes a document. An account manager drafts a follow-up email.

That is a sensible starting point, but it preserves the existing shape of the work.

“AI plus” turns the question around. If an AI system can handle much of the routine execution, what should the human contribute? Usually the answer includes context, priorities, taste, accountability, and judgment. The person is no longer responsible for manually performing every step, but remains responsible for defining the goal and validating the result.

This is a meaningful shift. A developer working with coding agents starts to resemble a development manager. A knowledge worker becomes an orchestrator of tasks and systems. The human role moves up a level—from producing every artifact to directing, reviewing, and improving the process that produces it.

That does not make expertise less important. It makes expertise easier to see. If you cannot recognize a bad result, set useful constraints, or explain what success looks like, faster output only helps you make mistakes faster.

The future of work is more likely to be redesigned than erased

Fear about job loss has followed generative AI from the beginning. Some roles will disappear, and new ones will emerge. But the more immediate change is that many existing roles will be redesigned.

Matthew is not a jobs doomer, and neither am I. The more grounded concern is not that every knowledge worker will be replaced overnight. It is that people who learn to work well with AI will have a growing advantage over those who do not.

Competence will mean more than writing a clever prompt. It will include breaking work into delegable pieces, choosing the right tool, supplying context, evaluating output, and knowing when a human decision is required.

That is why I resist the usual “do more with less” framing. It treats people as a cost to remove. A healthier goal is to do dramatically more with the people you already have—to give capable employees more room to test ideas, solve neglected problems, and spend less of their day on low-value coordination.

Matthew sees that pattern among the highly regulated organizations he supports. They have had to crawl, walk, and then run because they cannot allow an AI system to make certain final decisions. That constraint has helped keep the human in the loop from the beginning.

Regulation and governance can slow adoption, but slowness is not always failure. In high-stakes environments, the ability to explain permissions, preserve oversight, and assign accountability is part of the product—not paperwork added after the fact.

Cheap execution makes good requirements more valuable

The changes are especially visible in software development.

I shared an example of using agents to evaluate an existing repository, document its functional requirements, propose a phased plan, and help refactor it over a weekend. Work that once would have required a much larger commitment of time and people became cheap enough to attempt.

Matthew pointed to a reported rewrite involving Bun, Zig, and Rust as another sign of where this is going: coding agents can compress work that previously might have taken years. The specific tools will change, but the direction is clear. Code is becoming easier to regenerate, rewrite, and maintain.

When execution gets cheaper, the durable asset is the specification. What should the system do? How should permissions work? What behavior must remain unchanged? What does a correct outcome look like?

We may reach a point where teams define the desired behavior and let agents build the implementation repeatedly. But that does not eliminate the need for technical understanding. Someone still needs to inspect the work, test it, recognize risk, and decide whether the implementation is acceptable.

The developer who enjoys writing code may reasonably feel that something is being taken away. Coding can be meditative; managing agents is a different rhythm. Still, these tools can return another kind of creative freedom. People who have moved away from daily coding can prototype again. Teams can explore ideas that once died because nobody had time to build the first version.

The barrier between an idea and a working experiment is getting lower. That is not the end of creativity. It may be an expansion of who gets to create.

Connectors are where assistants become useful

A standalone chatbot can write and reason, but it cannot do much inside your working environment. Connectors change that.

Through Model Context Protocol (MCP) connections, plugins, and related integrations, an agent can reach the systems where work already lives: email, calendars, documents, Slack, and other enterprise tools. It can gather context across those sources and, when permitted, take an action.

I described a simple example from my own week. After a meeting, I needed to schedule time with several people and reserve a room. Instead of opening multiple calendars and comparing availability, I asked an assistant to find 30 minutes, invite the participants, and book a room. When one participant later said she would be remote, I asked it to add a Teams invitation. The agent already had the context.

No single step was especially difficult. That is the point. The day is full of small coordination tasks that each take 10 or 15 minutes and interrupt whatever matters more. When those minutes disappear across many tasks, people, and workdays, the benefit compounds.

For Matthew, connectors are not an occasional feature. They are part of nearly every interaction. An incoming customer email can be considered alongside official Google Docs and relevant Slack context. The system can help make sense of scattered information before helping with the next action.

The underlying tools are usually already present and already paid for. The new value comes from stitching them together.

Permission is the difference between assistance and risk

Connected agents are more useful because they can act. They are also more dangerous for the same reason.

The right response is not to reject connectors. It is to design permissions around consequences.

For example, an office connector might be allowed to read relevant information and create an email draft, but not send the message. The AI handles preparation; the human retains the final action. A different workflow may allow automatic scheduling but require approval before touching a production system.

“Human in the loop” should not be a vague reassurance. It should describe a specific control: who reviews what, at which step, with what information, and with the ability to stop or reverse the action.

Good governance makes useful experimentation possible. Bad governance tends to produce one of two outcomes: reckless access or a blanket prohibition that drives employees toward unapproved tools.

Memory and context are the next practical frontier

An assistant becomes more valuable as it learns the context of your work: which projects matter, how you communicate, where information lives, and which account or workflow fits a request.

Calling that capability memory is convenient, but incomplete. There is long-term knowledge that should apply across many tasks, and there is short-term context that matters only within the current workflow. Agent systems must decide what to retain, what to compact, and what to discard as conversations stretch from minutes into hours.

Bigger context windows help, but simply loading more information does not guarantee better attention. Another approach is delegation: give separate research, synthesis, validation, or compliance agents their own focused contexts, then coordinate their results.

That creates new work of its own. Prompt engineering has already expanded into context engineering, agentic engineering, and harness engineering. The labels may not last, but the need will: someone must design how these systems receive context, divide responsibility, use tools, and verify one another.

The best 90-day strategy is experimentation

Asked what teams should do over the next 90 days to six months, Matthew’s advice was simple: experiment.

That does not mean handing an autonomous agent the keys to the company. It means giving people safe opportunities to discover what these systems can do. Start with a recurring pain point. Use approved tools and non-sensitive data. Define the boundary of the task. Keep a human approval step where the consequences justify it. Then measure whether the workflow actually saves time or improves the result.

Most importantly, let employees use the tool to learn the tool. If you do not know where to start, describe your role and your repetitive work, then ask the assistant where it might help. The first answer may not be the right one, but it can expose possibilities you had not considered.

The mindset shift does not arrive through a strategy deck. It comes from repeated contact with the technology—trying something, seeing where it fails, adjusting the boundary, and eventually having your own “what if” moment.

Key takeaways

• The enterprise bottleneck is adoption, not raw capability. Many employees still use AI primarily as a better search tool.
• Think in terms of delegation. The important question is moving from “What can I ask?” to “What useful work can this system do for me?”
• Human expertise becomes more important, not less. People must define goals, supply context, review output, and remain accountable.
• Do not lead with headcount reduction. Use AI as a force multiplier that expands what capable teams can attempt.
• Requirements become more valuable as execution gets cheaper. Clear specifications and acceptance criteria are durable assets.
• Connectors create the biggest practical leap. Access to calendars, email, documents, and workplace systems turns a chatbot into an assistant.
• Permissions must reflect consequences. Keep explicit human approval at the points where errors could cause real harm.
• Experimentation builds understanding. Safe, repeated practice is how teams develop the mental model needed for agentic work.

Episode summary

Matthew Chenette joins Randy Bradshaw to examine why enterprise AI adoption trails the technology’s capabilities. They discuss the shift from chatbots to agents, how AI may reshape rather than simply eliminate jobs, the growing value of requirements in software development, and why connectors, permissions, memory, and experimentation determine whether AI becomes genuinely useful at work.

Chapters

• 00:00 — Meet Matthew and the role of an AI Success Engineer
• 04:19 — Why enterprise adoption trails AI capability
• 07:54 — From asking questions to delegating work
• 10:20 — “Plus AI” versus “AI plus”
• 12:06 — Jobs, changing roles, and human accountability
• 16:45 — Regulated industries and the 10x mindset
• 20:38 — Agents, legacy systems, and cheaper software execution
• 28:53 — Finding high-value uses beyond coding
• 35:29 — Developer resistance, flow state, and rapid prototyping
• 37:55 — Connectors, MCP, and removing coordination work
• 46:04 — Guardrails, permissions, and human approval
• 48:56 — Memory, context windows, and multi-agent workflows
• 56:26 — What teams should do over the next 90 days

People, products, and resources mentioned

People

• Matthew Chenette
• Randy Bradshaw
• Peter Steinberger

Products, technologies, and concepts

• ChatGPT
• Claude
• OpenClaw
• Codex
• Claude Code
• Model Context Protocol (MCP)
• Bun
• Zig
• Rust
• Python
• C#
• Microsoft Outlook and Exchange
• Microsoft Teams
• Slack
• Google Docs
• Microsoft Excel
• AI agents and agentic workflows
• Spec-driven development
• Context windows and context compaction
• Prompt engineering, context engineering, agentic engineering, and harness engineering

Closing thought

The signal is not that AI can answer more questions than it could six months ago. The signal is that it can participate in the work—if we give it the right context, the right tools, and the right limits.

Pick one recurring task this week and test that idea for yourself. Keep the scope small, keep a human in control, and pay attention to the moment when your question changes from “Can it do this?” to “What else could it do?”

Subscribe to Chasing the Signal for more practical conversations about AI, technology, and how to find what matters without getting swept up in the noise.