The Work Behind Enterprise AI: Permissions, Business Builders and the Value of Thinking

1. Host and Subject Background

Episode 251 of The Artificial Intelligence Show is an approximately 51-minute installment of AI Answers, the show's audience-question series. It is a discussion of enterprise adoption problems, rather than an interview with an outside guest. The distinction matters because its authority comes from the hosts' explanations, organizational experience and proposed applications, with different levels of evidential support for each.

The episode metadata names the usual pairing of Paul Roetzer and Mike Kaput, but the spoken introduction identifies Paul and Kathy McPhillips as this edition's hosts. Paul introduces himself as founder and CEO of SmarterX and Marketing AI Institute; Kathy is introduced as SmarterX's chief marketing officer. Paul also explicitly says Kathy is not replacing Mike. Kathy presents the questions and contributes observations, while Paul supplies most of the extended answers.

The questions were gathered from Intro to AI and Scaling AI classes, alongside other listener submissions. That origin gives the conversation its practical emphasis: participants want to know where to begin, what to automate and how to demonstrate useful capability. The episode also promotes SmarterX's AI Academy. Its enthusiasm for literacy, workshops and training therefore has a commercial context readers should recognize. That context does not settle whether the advice is useful; it helps distinguish a business-oriented discussion from an independent assessment of training effectiveness.

2. What the Episode Covers

The episode's central question is how organizations can make stronger AI capabilities usable within real operating constraints. Paul begins with regulated organizations: understand the concerns of governance stakeholders, the restrictions already in place and the relevant industry obligations, while identifying applications that stay within those boundaries. His healthcare example reaches beyond clinical work into marketing, sales, customer success, operations, HR and finance. His suggestion that thousands of opportunities may exist is an estimate, not an audited inventory or a finding that those functions are free of regulatory concerns.

A second obstacle is the gap between employees' experience of personal tools and the systems available at work. Paul describes users who know the reasoning and agent capabilities of Claude or ChatGPT but encounter more limited enterprise access. He recommends executive education that makes the business consequences of those limitations intelligible. This frames access as a capability decision with potential effects on growth and returns, although the episode does not calculate those effects or establish that every restriction is unjustified.

Shadow AI is the practical expression of that tension. Paul recalls a workshop at a large enterprise where the person responsible for model access and guardrails was also doing work through a personal account. He combines that anecdote with qualitative conversations to suggest the behavior is prevalent. He also acknowledges why reliable measurement is difficult: people would have to admit they were bypassing restrictions. The story exposes a possible mismatch between policy and working needs; it cannot establish an adoption or violation rate.

To make governance more precise, Paul separates reliability, autonomy and human involvement. His hypothetical marketing launch contains 25 steps: 15 follow explicit rules, while ten give AI room to plan, create or segment lists. A single workflow can therefore combine conventional automation and model-driven decisions. The useful question becomes what happens at each step, rather than whether the entire system carries the label “agent.”

His proposed starting point is low autonomy or limited consequences. An agent that privately reviews yesterday's marketing data is his example, provided its output is not sent externally, automatically activated or assumed correct. Platform selection receives a similar separation of concerns. Paul says SmarterX provides Gemini, Claude and ChatGPT licenses for roughly $60 per person monthly, while centrally controlling connections to CRM and financial systems. Most employees, he suggests, can develop depth in one platform while an experienced group compares alternatives.

The larger ambition is proactive assistance: an agent notices a webinar-registration surge, associates it with a successful LinkedIn advertisement and recommends further action and alternative copy. That scenario illustrates the shift from answering requests to surfacing opportunities. It remains an imagined application. Paul's expectation that such capabilities will enter enterprises within six months is a forecast, not evidence that this particular system has been deployed or produced results.

3. Core Views: Reasoning, Examples, and Limits

The strongest governance idea in the conversation is to assess decisions and permissions at the level where they occur. In Paul's 25-step example, rule-following actions and model-generated judgments require different kinds of supervision. Yet explicit rules do not by themselves establish that the input data is appropriate. His internal analyst example adds a second dimension: an agent may exercise discretion in analysis while having little authority to affect the outside world. Separating analytical autonomy from execution authority makes the proposed starting point more useful than a general instruction to proceed cautiously.

The shadow AI anecdote explains why capability belongs in that discussion. A person who understands the guardrails may still find the approved tools inadequate for the work. That is a reason to investigate the gap, not evidence that bypassing controls is acceptable. Nor does Paul's experience establish how often this happens elsewhere. Executive education could clarify the tradeoff, but it cannot replace decisions about particular data and actions. SmarterX's reported licensing arrangement likewise illustrates one organizational choice; neither its price nor its mix of platforms is a universal procurement benchmark.

Paul's argument about builders is more ambitious. He describes forward-deployed engineers as technical people who enter organizations, understand workflow problems and construct solutions, attributing the model's popularization to Palantir. He regards them as important now, but expects trained business practitioners to reduce dependence on them within one or two years. Over a longer horizon, he imagines centralized groups of strategically minded business builders supporting departments through workshops, boot camps and hackathons.

The reasoning is that business understanding already resides close to the problem, while easier prototyping reduces the distance between an idea and something others can inspect. His example of producing an interactive prototype rapidly supports that narrower point. It does not demonstrate reliable production delivery, continued maintenance or a complete allocation of responsibility among IT, HR and business leaders. His staffing forecast depends on substantial training and tool progress. Readers can take the opportunity for business participation seriously without treating the predicted timetable as established.

His defense of conventional automation provides a useful restraint. OCR, RPA and agent capabilities may blend together, but a clear if-then task need not use an advanced model. This connects to his distinction between optimization and innovation. Mapping tasks and desired outcomes helps improve an existing process; asking whether the process should exist addresses a different problem. His references to automating 30% of a workflow or spotting ten hours of monthly savings illustrate differences in diagnostic ability. They are not measured savings that another organization can assume.

The overloaded-owner question shows why this is also an operating-model decision. Before discussing automation, Paul asks whether the owner wants to hire. Maintaining a small staff and building a larger team are different choices. Within the first path, repetitive, data-driven work offers a starting point, alongside an assessment of employees' AI maturity. Kathy adds that faster customer answers must coexist with relationship maintenance. Removing administrative effort does not automatically resolve the judgments and relationships that make the owner central.

For service providers, authority precedes production. Paul advises clarifying contractual restrictions, disclosure, client approval and copyright transfer before creating work. His comments identify matters to resolve with a client; they do not determine the legal effect of any particular contract. His commercial assessment also requires calibration. He has only watched a trailer for Marketing Studio and explicitly has not studied it deeply. That discussion cannot support a definitive product review.

The more substantive service argument concerns what clients are purchasing. Paul and Kathy have heard marketing executives express plans to bring outsourced work in-house. Paul argues that pricing becomes harder when clients know production is largely AI-driven and understand its cost. At the same time, some clients may still prefer a trusted outside partner to execute and decide where human involvement matters. Training could be a steadier offering, he suggests, but only if the provider can make it profitable and grow it. Switching service categories does not establish commercial durability.

Relationship work offers a concrete version of that division of labor. The hosts discuss how embedded HubSpot AI can use business and content-performance information already in the platform. Paul also imagines an agent gathering public interviews, talks and podcast material, proposing a relevant reason to contact someone and drafting a message for a person to finish. He sees applications in fundraising, sales, customer success and account-based marketing. He is uncertain whether universities and nonprofits face higher authenticity expectations than other organizations. The example supports a possible preparation workflow, not a demonstrated increase in donations, sales or trust.

Finally, Paul treats learning as an outcome separate from text production. He estimates that, with suitable models and extensive context, AI could handle about 95% of his relevant writing if it did not depend heavily on personal anecdotes. That is a personal estimate, not a general replacement rate. He continues writing because it builds understanding and confidence. Both hosts also continue taking notes; Paul finds typing helpful for retention and observes that transcripts miss aspects of tone and pauses. These are personal explanations for preserving an activity, not controlled evidence about how everyone learns.

4. Learning and Application

A practical way to apply the episode is to select a bounded workflow and make its permissions visible. Building on Paul's distinction between autonomy and consequences, record the source of each input, whether a rule or a model makes the decision, who receives the output and whether anything happens automatically afterward. An internal analytical pilot can stop at a recommendation, with a person checking it before a separate action. This is an application of his framework, not a compliance certification. A department's name or an approved software purchase does not settle the suitability of a particular use.

Platform learning and data connections can then be decided separately. Most employees might practice real tasks in one system, while a smaller experienced group compares platforms on the same work. CRM and financial connections require their own decisions. The benefit is focused learning with room for comparison; the tradeoff is that this arrangement still needs coordination and may not fit every organization. SmarterX's three-license configuration is an example to evaluate, not a package everyone should copy. In workflow design, use explicit rules where they suffice and consider both improving the current process and replacing its underlying structure.

For an individual, Paul's strongest career advice is to build something specific to the prospective employer. Start with a responsibility, goal or KPI in the role, research relevant public material and produce a prototype or sample analysis. He mentions earnings statements and executive earnings-call comments for publicly traded companies. Any inferred business goal should remain labeled as an inference. Personally verify the material and be ready to explain the problem, the proposed use and the limitations. The same approach works for an internal proposal: his ten-slide deck and fifteen-minute meeting are illustrative formats for making a business case tangible.

A project-management portfolio could test his imagined launch-control-center concept. Use clearly sourced progress information, identify possible delays, suggest questions for the manager and draft communications for review. Paul reports using Asana and its built-in AI but is uncertain about a ChatGPT connection; the broader control center should therefore be presented as a proposed application. His example of AI handling ten of twenty steps and saving five hours is hypothetical. Any portfolio claim about time saved should come from actual comparison, including the work required to check the output. A role-forecasting tool can help generate possibilities, while the employer's actual requirements still need investigation.

Service providers can begin with an agreed scope for AI use, disclosure, approval and copyright arrangements, then clarify whether the client is buying production, outside judgment or capability development. Training may suit clients who want to take work in-house, but its economics still need testing. For relationship work, the public-information research and drafting stages can be separated from the final human decision to contact someone. Verify that the proposed connection is accurate and appropriate to the channel; a personalized draft is not proof of a stronger relationship.

For work intended to develop expertise, preserve an opportunity to formulate an argument or take notes personally. This follows from Paul's stated preference rather than a universal requirement. The useful question is whether the author only needs a deliverable or must later explain and apply its substance independently.

Finally, budget from observed usage. Paul considers token or compute negotiations unusual for nontechnical applicants, but reports additional ChatGPT usage requests roughly every three days and recurring HubSpot credit limits in his organization. His recommendation to consider 2027 token budgets supports recording which tasks hit limits and what additional capacity enables. It supplies no standard allowance or return threshold. Neither his team's request frequency nor the amount an employee consumes should be treated as a universal measure of contribution.

Source

• Original episode: Ep. 251: Forward-Deployed Engineers, Shadow AI, Owner Bottleneck, AI on Your Resume & Token Budgets