Ask ChatGPT about your company’s refund policy. It will make one up.

Ask it to summarise last quarter’s sales performance. It will invent numbers that sound plausible.

Ask it what your Leadership team said in the last all-hands meeting. It will fabricate a quote so realistic you might believe it for a moment before remembering that ChatGPT was not in the meeting.

This is not a bug. This is how the technology works.

ChatGPT was trained on public internet data. Books, websites, articles, forum posts. It knows an extraordinary amount about the world in general. It knows nothing about your company in particular.

It has never read your internal wiki. It has never seen your CRM data. It does not know your product roadmap, your pricing structure, your org chart or the three strategic priorities your leadership team agreed on last all hands.

When you ask it about any of these things, it does not say “I do not know.” It predicts what a reasonable answer would look like based on patterns from its training data. And those predictions are confident, well-structured but completely disconnected from the reality.

This is the gap that makes most professionals say “AI is interesting but not useful for my actual work.”

RAG closes that gap.

What RAG actually is?

RAG stands for Retrieval Augmented Generation. The name sounds technical. The concept is simple.

Before the AI generates a response, it first searches through your documents and retrieves the relevant information. Then it uses that retrieved information to generate its answer. The answer is grounded in your actual data, not in the AI’s training data.

Retrieval first. Then generation. That is why it is called Retrieval Augmented Generation.

Without RAG, the AI guesses based on what it learned from the internet. With RAG, the AI answers based on what it found in your documents. Same model. Same technology. Fundamentally different output.

Lets understand with an example

You contact Amazon support and say “Where is my order?” The agent does not guess. They do not say “Based on typical shipping patterns, your order is probably in transit.” They pull up your actual order. They check the actual tracking number. They see the actual status. They tell you “Your order shipped on Tuesday, it is currently in the ABC sorting facility, and the estimated delivery is Thursday.”

Every word is grounded in real data. Not patterns. Not predictions. Your order. Your tracking number. Your delivery date.

Now imagine if the agent had no access to the order system. You ask “Where is my order?” and the agent says “Most orders from this region arrive within 3–5 business days. Based on standard shipping patterns, your order is likely in transit and should arrive soon.” It sounds helpful. It is completely useless. Because it is not about your order. It is about orders in general.

That is the difference between ChatGPT without RAG and ChatGPT with RAG.

Without RAG, the AI is a support agent who has handled millions of customer queries but has no access to your account. They give you generic answers based on what is usually true. With RAG, the AI is a support agent who has your full account open on their screen. Every answer is specific to your situation because they are looking at your actual data.

How RAG works ? Five step process, no code.

Even if you are a non-technical person, you need to understand what happens under the hood.

You do not need to build RAG from scratch but understanding the mechanism helps you use it better, troubleshoot when it fails and evaluate whether a vendor’s RAG implementation is actually good.

Step 1: Your documents get chunked.

Your company has hundreds or thousands of documents. Policy manuals. Product specs. Meeting transcripts. Sales reports. Client proposals. Training materials.

RAG starts by breaking these documents into smaller pieces called chunks. A chunk might be a paragraph, a section or a page. The size depends on the system’s configuration.

Why not keep documents whole? Because AI models have limited context windows. You cannot paste a 200-page policy manual into ChatGPT and ask a question. It will not fit. Even if it fits, the model struggles to find the relevant needle in a 200-page haystack. Chunking breaks the haystack into small, searchable pieces.

Step 2: Each chunk gets converted into numbers.

This is the embeddings concept. Each chunk of text gets converted into a list of numbers that represent its meaning. These numbers capture what the text is about, not just what words it contains.

A chunk about “employee vacation policy” and a chunk about “annual leave entitlement” would have similar embeddings even though they use different words because they mean the same thing.

These embeddings are stored in a special database called a vector database. Think of it as a library catalog that organises books by meaning, not by title.

Step 3: Your question gets converted into numbers too.

When you ask a question — “How many vacation days do new employees get?” Even the question gets converted into an embedding. A list of numbers that represents the meaning of your question.

Step 4: The system finds the closest matches.

The vector database compares the question’s embedding against every chunk’s embedding. It finds the chunks whose meanings are closest to the question’s meaning.

“How many vacation days do new employees get?” will match chunks from the employee handbook that discuss vacation policy, onboarding benefits and leave entitlement. It will not match chunks about expense reports or parking policies because those embeddings are far away in meaning space.

The system retrieves the top 3–5 most relevant chunks. Think of it like pulling the correct set of books from a library shelf.”

Step 5: The AI generates an answer using the retrieved chunks.

The retrieved chunks get inserted into the AI’s prompt along with your question. The prompt now looks something like:

“Using the following company documents, answer the user’s question. Only use information from the provided documents. If the answer is not in the documents, say so.

[Document chunk 1: Employee Handbook, Section 4.2 — New employees receive 18 days of paid vacation per calendar year, prorated for the first year based on start date…]

[Document chunk 2: Onboarding Guide, Page 12 — Vacation accrual begins on the first day of employment at a rate of 1.5 days per month…]

Question: How many vacation days do new employees get?”

The AI reads the chunks, synthesizes the information, and generates: “New employees receive 18 days of paid vacation per year, prorated in their first year. Vacation accrues at 1.5 days per month starting from the first day of employment.”

That answer came from your documents. Not from the internet. Not from the AI’s training data but from the company’s actual employee handbook.

That is RAG. That is the entire mechanism.

Why RAG matters more than fine-tuning

When professionals first hear about making AI work with company data, they usually think about fine-tuning. Training the AI model on their company’s data so the model “learns” the company’s information.

RAG and fine-tuning solve the same problem. But they solve it very differently. And for most business use cases, RAG is the better choice.

Fine-tuning takes your data and bakes it into the model’s weights. The model permanently absorbs the information. This is expensive, slow and requires retraining every time your data changes. If your product pricing changes next month, you need to fine-tune again. If a new policy is issued, you need to fine-tune again. The model’s knowledge becomes stale the moment your data updates.

RAG keeps your data separate from the model. The model does not learn your data permanently. It reads your data every time it answers a question. Update a document? The next answer reflects the update immediately. Add a new policy? It is searchable instantly. Remove outdated information? It disappears from answers immediately.

Think of it this way.

Fine-tuning is like memorising a textbook. Once memorized, you do not need the book. But when the textbook gets a new edition, your memorised version is wrong and you need to study all over again.

RAG is like having the textbook open on your desk. You look things up as needed. When a new edition arrives, you swap the book. Your answers are always current because you are always reading the latest version.

For most businesses, data changes frequently. Prices update. Policies change. Products evolve. Team structures shift. RAG handles this naturally because the source documents are always current. Fine-tuning struggles because the model needs to be retrained every time something changes.

When fine-tuning makes more sense

Fine-tuning is better than RAG in one specific scenario: when you need the model to adopt a specific style, voice or behavior pattern that is consistent across all interactions.

If you want your AI to always respond in your brand voice, always follow your company’s communication guidelines and always structure answers in a specific format, fine-tuning encodes these behaviours into the model permanently. RAG cannot do this because RAG provides information, not behaviour.

The best enterprise AI systems use both. Fine-tuning for style and behaviour. RAG for facts and data. The model behaves like your company. The answers reflect your company’s current information.

Where RAG is being used right now

RAG is not experimental. It is the most widely deployed enterprise AI pattern in 2026.

Internal knowledge assistants

This is the most common use case. A company builds an AI assistant that can answer questions about internal policies, processes and procedures.

“What is our parental leave policy for employees in the London office?” The AI searches the employee handbook, finds the UK-specific parental leave section, and provides the accurate answer with the source document referenced.

Without RAG, every employee sends this question to HR. HR answers the same question hundreds of times per year. With RAG, the AI handles it instantly. HR handles only the edge cases that require human judgment.

Customer support

A customer asks: “Does your Enterprise plan include SSO integration?” The AI searches the product documentation, finds the Enterprise plan feature list and confirms that SSO is included. It can even link to the setup guide.

Without RAG, the support agent opens the product docs, searches for the answer and types a response. With RAG, the AI does all of this in seconds. The agent reviews and sends. Or the AI sends directly if the confidence is high enough.

Sales enablement

A sales rep is preparing for a client meeting. They ask the AI: “What case studies do we have for retail companies that implemented our demand forecasting product?” The AI searches the case study library, finds three relevant examples, and summarizes each with the key results and the client’s industry.

Without RAG, the sales rep searches through SharePoint, asks colleagues on Slack, and eventually finds one case study from two years ago. With RAG, they have three in 30 seconds.

The three reasons RAG fails (and how to prevent each one)

RAG is powerful. It is not magic. When RAG produces bad answers, it is almost always because of one of three reasons.

Failure 1: Bad documents in, bad answers out.

RAG retrieves from your documents. If your documents are outdated, contradictory, incomplete, or poorly written, the AI will retrieve bad information and generate bad answers. Confidently.

The AI does not judge document quality. It retrieves the closest semantic match. If your employee handbook from 2019 says vacation is 15 days and your 2024 update says 18 days, and both documents are in the system, the AI might retrieve either one. The answer depends on which chunk matches better, not which document is newer.

The fix: Before deploying RAG, audit your document library. Remove outdated versions. Resolve contradictions. Ensure the most current version of every document is the one the system indexes. This is not a technical task. It is a housekeeping task. And it is the single biggest determinant of RAG quality.

Failure 2: The chunks are the wrong size.

If chunks are too small, the AI retrieves fragments that lack context. “18 days” without the context that this applies to “new employees in full-time roles” is an incomplete answer.

If chunks are too large, the AI retrieves passages that contain both relevant and irrevelant information. The model gets confused about which parts to use.

The fix: Chunk size needs to match your document structure. For well-structured documents with clear sections (policy manuals, product docs), chunk at the section level. For unstructured documents (meeting transcripts, emails), chunk at 200–500 word segments with some overlap between chunks so context is not lost at boundaries.

Most RAG platforms let you configure chunk size. The default is usually fine. But if answers are consistently missing context or including irrelevant details, chunk size is the first thing to adjust.

Failure 3: The AI ignores the retrieved documents and answers from its own training.

This is the most frustrating failure. You set up RAG. You uploaded the documents. The system retrieves the right chunks. But the AI’s answer does not match what the documents say. It answers from its general knowledge instead of from the retrieved content.

This happens when the prompt does not strongly enough instruct the model to use only the provided documents.

The fix: The prompt engineering matters enormously. Include explicit instructions: “Answer ONLY using the provided documents. If the answer is not in the documents, say ‘This information is not available in the current documents.’ Do not use your general knowledge.”

This constraint forces the model to stay grounded in the retrieved content. It also gives you a clear signal when the documents do not contain the answer, which is far more useful than a hallucinated response.

RAG is the technology that turns AI from “interesting but generic” into “actually useful for my business.”

The companies that have deployed RAG are getting real answers from real data. The companies that have not are still getting confident guesses from a model that has never seen their documents.

If you like this article, you will absolutely love our AI Program Management Course ( having real AI PM Interview Questions from Google, OpenAI, Anthropic, Amazon etc) — ( 32+ Videos ) & ( Extra 25+ Real Case studies as well )

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Now sort every item into two buckets.

Bucket A: Tasks that follow the same steps every time you do them. The inputs change. The process does not. Status updates. Meeting notes. Data entry. Invoice processing. Email sorting. Report formatting. Calendar scheduling. Follow-up reminders.

Bucket B: Tasks that require you to think differently every time. Client negotiations. Strategic decisions. Creative problem-solving. Team conflicts. Ambiguous situations where the right answer depends on context, relationships and judgment that only you have.

Most professionals discover that Bucket A is 50–70% of their week. Sometimes more.

That entire bucket can be automated. Not someday. Right now. With tools that already exist.

But here is the part most articles about automation get wrong. They tell you to automate everything. That is terrible advice. Some things should not be automated. Some things cannot be automated. And the professionals who automate the wrong things end up causing more damage than the ones who automate nothing.

The automation test. Three questions.

Before automating anything, run it through three questions. If the task passes all three, automate it. If it fails any one of them, keep it human. Or add a human review layer.

Question 1: Does this task follow a repeatable pattern?

This is the most fundamental filter.

AI automation works on patterns. If the task follows the same steps every time, a machine can learn those steps and execute them. If the task changes significantly each time, a machine cannot predict what to do.

Repeatable: Every Monday, pull completed tasks from Jira, summarise them in a status update, and email it to my manager. The format is the same. The data source is the same. The recipient is the same. Only the content changes week to week.

Not repeatable: Decide whether to restructure the engineering team based on the upcoming product roadmap, the current team dynamics, the budget constraints and the CEO’s shifting priorities. Every restructuring decision is different. The variables are different. The context is different. The trade-offs are different.

The first task is a pattern. Automate it. The second task is a judgment call. Keep it human.

Question 2: Can the task tolerate occasional errors?

Every automation will make mistakes. Not many. But some. The question is whether the cost of those mistakes is acceptable.

Can tolerate errors: An AI sorts your inbox into four categories. It misclassifies 5% of emails. A newsletter ends up in “Action Required.” An FYI ends up in “Notification.” Annoying. Not damaging. You catch it during your daily review. The time saved by correctly classifying 95% of emails far outweighs the cost of the 5% that are wrong.

Cannot tolerate errors: An AI automatically sends refund confirmations to customers who file complaints. It processes a complaint that is actually a compliment phrased sarcastically. It issues a refund the customer never asked for. The company loses money. The customer is confused. The manager has to explain what happened.

The first scenario has low error cost. Automate it. The second scenario has high error cost. Either do not automate it, or automate the drafting and add a human approval step before the action executes.

Question 3: Does the task require reading the room?

This is the filter that separates good automation from dangerous automation.

“Reading the room” means understanding context that is not in the data. The tone of a conversation. The political dynamics between stakeholders. The unspoken frustration behind a politely worded email. The history between two people that changes the meaning of everything they say.

Does not require reading the room: Transcribe a meeting and extract the action items. The words were spoken. The AI captures them. The action items are explicit. “John will send the revised proposal by Friday.” No interpretation needed.

Requires reading the room: Decide who should deliver bad news to the client. The data says the project is late. That is a fact. But who delivers that message the project manager, the account lead, or the VP depends on the client relationship, the severity of the delay, the client’s personality and the political dynamics of the account. No dataset captures this. No automation can learn it.

If the task requires understanding human dynamics that exist outside the data, keep it human.

The automation spectrum. Not binary. A gradient.

Here is where most automation advice fails. It presents automation as binary. Automate or do not automate. Yes or no.

Reality is a spectrum. Most tasks are not fully automatable or fully human. They are somewhere in between. And the right approach is to automate the parts that are pattern-driven and keep the parts that require judgment.

Think of it as a five-level spectrum.

Level 1: Fully automated. No human in the loop.

The task runs start to finish without any human involvement. Set it up once. It runs forever.

Examples: Email sorting and labelling. Calendar event creation from email invitations. File backup and organisation. Data syncing between apps. Recurring report generation from fixed data sources.

When this works: The task is 100% pattern-driven, errors are cheap, and no judgment is needed at any step.

Level 2: Automated with human review.

The AI does the work. A human checks it before it goes out.

Examples: AI drafts a status update. You review it for 2 minutes and hit send. AI generates a client email. You scan it, adjust one line and send. AI creates a meeting summary. You verify the action items are correct before distributing.

When this works: The task is mostly pattern-driven but the output goes to someone important (a client, a leader, an external partner) where an error would be embarassing or damaging.

This is the sweet spot for most professional work. AI handles 90% of the effort. You handle 10%. The total time drops from 45 minutes to 5 minutes. The quality stays the same or improves because the AI does not forget things the way your tired Friday afternoon brain does.

Level 3: AI-assisted. Human leads, AI supports.

The human does the core work. The AI provides inputs, research, drafts or analysis that accelerates the human’s work.

Examples: You are preparing for a negotiation. AI researches the counterparty’s recent public statements, financial performance and competitive position. You read the research and build your strategy. AI did not negotiate. It gave you better inputs for your negotiation.

You are writing a strategic proposal. AI drafts a first version based on your outline and context. You rewrite 40% of it, adding the insights that only come from your expertise and your relationship with the client. AI accelerated the drafting. You did the thinking.

When this works: The task requires significant judgment but has components (research, drafting, data gathering) that are pattern-driven and can be delegated to AI.

Level 4: Human only with AI monitoring.

The human does all the work. AI watches in the background and flags issues.

Examples: You manage a portfolio of client accounts. AI monitors the accounts for unusual activity like a sudden drop in engagement, a spike in support tickets, a lapse in communication. It does not take any action. It sends you an alert. “Account X has not logged in for 14 days. This pattern historically correlates with churn risk.” You decide what to do about it.

When this works: The judgment is entirely human but the monitoring is too tedious or too data-intensive for a human to do consistently. AI watches the signals. You make the calls.

Level 5: Fully human. AI should not be involved.

The task is entirely about judgment, relationships, emotion or ethical reasoning. AI adds no value and potentially adds risk.

Examples: Delivering a cancer diagnosis. Mediating a conflict between two senior leaders. Deciding whether to shut down a product line that 50 people depend on for their livelihood. Writing a condolence note to a colleague who lost a family member.

These are tasks where the human element is not just part of the value. It is the entire value. An AI-generated condolence note is worse than no note at all. An AI-mediated conflict resolution lacks the empathy and the political sensitivity that resolution requires.

When this applies: When the quality of the outcome depends on the recipient feeling that a real human genuinely engaged with their situation. Automation here does not save time. It destroys trust.

The four categories of automatable work

Now let us get practical. Here are the four categories of work that are most commonly automated by professionals in 2026. If your work touches any of these categories, you have automation opportunity.

Category 1: Information gathering and synthesis

Pulling data from multiple sources. Compiling reports. Summarising documents. Researching competitors. Scanning news for relevant updates.

This category is the easiest to automate because it is pure pattern work. The sources are defined. The format is defined. The output structure is defined. AI tools like Perplexity, ChatGPT, and Zapier integrations handle this well.

Example: Every morning, AI pulls the top 5 industry news stories from three sources, summarises each in two sentences, and delivers them to your inbox at 7:00 AM. You read them over coffee. You are informed before your first meeting. Total human effort: 3 minutes of reading.

Category 2: Communication processing

Email sorting. Message prioritisation. Meeting transcription. Follow-up tracking. Response drafting.

This category saves the most time because communication is the largest single time consumer for most professionals. The volume is high. The patterns are clear. The error cost is low.

Example: Every email you receive gets classified as “Action Required,” “FYI,” “Newsletter,” or “Notification.” You check the Action Required label first. Everything else waits. The 35-minute morning inbox scan becomes an 10 minutes targeted review.

Category 3: Document creation

Status updates. Reports. Proposals. Meeting summaries. Presentations. Standard deliverables that follow a consistent format.

This category is the most satisfying to automate because the before-and-after is dramatic. A report that took 90 minutes now takes 10 minutes of review.

Example: Every Friday at 2:00 PM, AI pulls data from your analytics dashboard, CRM and project management tool. It compiles a formatted weekly business review. You review it at 2:30 PM. Edit two sentences. Send it by 3:00 PM. Your Friday afternoon is free.

Category 4: Data monitoring and alerting

Tracking metrics for anomalies. Monitoring dashboards. Watching for threshold breaches. Scanning for patterns that indicate a problem.

This category is the most underused. Most professionals check dashboards manually once a day if they are disciplined, once a week if they are busy. AI can monitor continuously and alert only when something needs attention.

Example: AI monitors your product’s daily active users. If DAU drops more than 15% compared to the same day last week, you get an alert with the breakdown by segment. You do not check the dashboard every morning hoping to catch problems. The automation catches them for you. Instantly. Every time.

What should NOT be automated

This section matters as much as everything above. Because the damage from automating the wrong thing is often worse than the cost of not automating the right thing.

Do not automate relationship-critical communications. A client escalation email. A partnership negotiation. A board communication. An investor update. These are communications where the specific words matter, the tone matters, the timing matters, and the sender’s personal engagement matters. AI can draft. A human must own.

Do not automate anything you do not fully understand. If you cannot explain the steps of a process clearly, you cannot automate it well. Automation encodes your process into a machine. If the process is unclear, the automation will be unclear. It will make mistakes you cannot diagnose because you did not understand the process well enough to define it properly.

Do not automate without a kill switch. Every automation should have a way to stop it immediately. If the AI starts sending wrong emails, you need to stop it in seconds, not hours. If the classification model starts miscategorising urgent emails as newsletters, you need to revert to manual processing instantly. Build the kill switch before you need it.

The one thing to remember from today

Not everything should be automated. But everything that follows a repeatable pattern, tolerates occasional errors and requires no human judgment absolutely should be.

That is probably 50–70% of your current work week.

The professionals who draw the automation line clearly will reclaim hours every week. The professionals who automate blindly will create new problems. The professionals who automate nothing will fall behind professionals who automate wisely.

If you like this article, you will absolutely love our AI Program Management Course ( having real AI PM Interview Questions from Google, OpenAI, Anthropic, Amazon etc) — ( 32+ Videos ) & ( Extra 25+ Real Case studies as well )

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Every interaction follows the same pattern. You ask. It responds. You ask. It responds. The conversation moves forward one message at a time.

ChatGPT never does anything unless you tell it to. It never acts on its own. It waits for your next user prompt.

This is a chatbot. Reactive. Conversational. Helpful. But fundamentally passive.

Now imagine something different.

You type: “Book me a flight from Mumbai to London for next Tuesday under 50,000 rupees. Economy class. Window seat. Morning departure. Add the confirmation to my calendar and send the itinerary to my assistant.”

You hit enter. You go make coffee. You come back.

The flight is booked. The calendar is updated. Your assistant has the itinerary.

You did not compare airlines. You did not check six websites. You did not copy confirmation numbers into a calendar event. You did not draft a forwarding email. You gave one instruction. The system did everything else.

That is an AI agent. And it is the most important shift in AI since ChatGPT launched.

The major difference

A chatbot generates text. An agent takes action.

That is the entire difference. It sounds small. It changes everything.

When ChatGPT writes you a to-do list, you still have to do every item on the list. When an AI agent receives that same to-do list, it starts doing the items.

ChatGPT can tell you step by step how to fix a code error. An AI agent actually goes ahead and fixes the error.

ChatGPT can draft an email. An AI agent drafts the email, sends it, logs it in the CRM and schedules a follow-up for next week.

The gap between “tells you what to do” and “does it for you” is the gap between a chatbot and an agent. One informs. The other executes.

How an AI agent actually works

Let us go one level deeper. Not into the code. Into the logic.

An AI agent has four capabilities that a chatbot does not.

1. It can use tools

ChatGPT lives inside a text box. It can read text and generate text. That is its world.

An AI agent can reach out and interact with other systems. It can search the web. It can query a database. It can call an API. It can read a spreadsheet. It can send an email. It can update a CRM record. It can create a calendar event. It can trigger a workflow in another application.

These external connections are called tools. Each tool gives the agent one capability. A search tool lets it find information. An email tool lets it send messages. A calendar tool lets it create events. A CRM tool lets it update records.

The more tools an agent has access to, the more it can do. An agent with access to your email, calendar, CRM and project management tool can coordinate across all four systems in a single action. A human doing the same thing would need to open four applications and manually copy information between them.

2. It can plan

When you give ChatGPT a complex request, it produces one response. If that response is incomplete, you send another message. Then another. You are managing the process.

An AI agent plans. You give it a goal. It breaks the goal into steps. It figures out the sequence. It decides which tools to use for each step. Then it executes the steps in order.

“Research the top 5 competitors in the Indian EV market, create a comparison table, and email it to my team by 5pm.”

The agent breaks this into steps.

→ Search for Indian EV market competitors. Identify the top 5 by market share.
→ Gather data on pricing, range, and features. Create a structured comparison table.
→ Draft an email with the table attached.
→ Send the email to the team distribution list.

Each step uses a different tool. The agent orchestrates all of them.

You gave one instruction. The agent made a plan, executed the plan and delivered the result. You did not manage the process. The agent managed itself.

3. It can observe and adjust

This is where agents get genuinely interesting.

A chatbot generates a response and stops. It does not check whether the response was useful. It does not monitor the outcome. It does not correct itself.

An AI agent observes the results of its actions and adjusts.

The agent tries to book a flight. The first API call fails because the flight is sold out. The agent does not stop and report an error. It searches for alternative flights. It finds one that is 2,000 rupees over budget but arrives 30 minutes earlier. It makes a judgment call and presents the option to you. “The exact match is sold out. I found an alternative for 52,000 rupees arriving at 9:15am instead of 10:00am. Should I book it?”

This observe-adjust loop is what makes agents feel intelligent. They do not blindly follow a script. They respond to what actually happens in the real world. When things go wrong, they adapt.

4. It can operate autonomously

This is the biggest difference. And the most consequential one.

A chatbot does nothing unless you send a message. It is always waiting for you.

An AI agent can operate in the background without you. It can monitor your email inbox and flag urgent messages. It can watch your calendar for conflicts and suggest resolutions. It can track project deadlines and send reminders before things are late. It can process incoming customer queries while you sleep.

The agent does not need you to be present. You set the goal, the boundaries and the permissions. The agent runs. You check in when you want to. Not because the agent needs you to tell it what to do next.

This is the shift from AI as a tool you use to AI as a worker that operates alongside you.

Real agents working in real companies right now

This is not future speculation. AI agents are deployed in production at major companies today.

Salesforce Agentforce

Salesforce rebranded its entire platform around AI agents in 2025. Agentforce is the most widely deployed enterprise AI agent system in the world.

In many deployments, AI agents are resolving a majority of customer inquiries on their own and managing large volumes of conversations. The SDR agent works 24/7 — handling outbound prospecting, follow-up, and meeting booking at volumes no human SDR team can match.

Agentforce launched with seven pre-built agent types: Campaign Optimizer, Service Agent, Buyer, Personal Shopper, Merchant, Sales Development Representative, and Sales Coach. Since then, Salesforce has shipped vertical packages for retail, field service, HR, financial services, manufacturing, IT service and more.

The pricing model tells you everything about where this is heading. Agentforce charges $2 per conversation. Not per seat. Not per month. Per conversation. You pay for what the agent does, not for a license that sits unused. This is pricing for a digital worker, not pricing for software.

OpenTable

OpenTable deployed a Salesforce Agentforce-based agent to handle diner and restaurant inquiries. The agent autonomously handles 70% of diner and restaurant inquiries. Reservation changes, booking confirmations, restaurant questions. The agent handles them without a human touching the conversation. The 30% that require human judgment get escalated automatically.

Shopify Sidekick

Shopify operates Sidekick, an agentic merchant assistant that lets store owners query data, fill product forms, write SEO content and navigate the admin through natural language.

A store owner says “Show me my best-selling products last month and create a 15% discount code for each one.” Sidekick queries the data, identifies the products, creates the discount codes and presents the results. The store owner did not navigate five screens. They typed one sentence in natural language.

GitHub Copilot Coding Agent

GitHub Copilot’s coding agent is among the most widely cited agentic AI deployments. It does not just suggest code completions. It can take a task description, write the code, create a pull request, and run tests. A developer assigns a task. The agent completes it. The developer reviews the result.

The three levels of AI agent autonomy

Not all agents are equally autonomous. Understanding the levels helps you decide how much control to give up and where.

Level 1: Human-directed. The agent executes one task at a time. You give an instruction. It acts. It reports back. You give the next instruction. Think of it as a very capable assistant that can use tools but still needs you to direct every step.

Example: “Summarise the last 10 customer support tickets and categorize them by issue type.” The agent does it. Waits for your next instruction.

Level 2: Semi-autonomous. The agent takes a goal and breaks it into steps. It executes most steps independently but checks in with you at critical decision points. It handles routine actions on its own. It escalates exceptions.

Example: “Process all new customer refund requests. Approve any under 5,000 rupees automatically. Flag anything above 5,000 for my review.” The agent handles the routine refunds without you. It escalates the large ones.

Level 3: Fully autonomous. The agent operates continuously in the background. It monitors, acts and adjusts without human intervention. It only escalates when it hits a situation outside its defined boundaries.

Example: “Monitor our social media mentions. Respond to positive mentions with a thank you. Route negative mentions to the support team. Escalate any mention from a verified account with more than 10,000 followers to the PR team immediately.”

Most enterprise deployments today are at Level 2. Level 3 is emerging in specific use cases like customer service triage and IT ticket resolution. Level 1 is where most professionals interact with agents through tools like Claude, ChatGPT with plugins or Copilot.

Why this matters for managers

If you are a manager in any function, AI agents change three things about your job.

1. You are now managing digital workers, not just human teams.

A PwC survey found that 73% of respondents agree that how they use AI agents will provide a significant competitive advantage in the next 12 months.

The organizations deploying agents are not replacing humans wholesale. They are creating hybrid teams. Human workers handle judgment, relationships and complex decisions. AI agents handle volume, speed and repetitive execution.

The manager’s job expands. You are not just managing people. You are managing people and agents. Defining what agents can and cannot do. Monitoring agent performance. Deciding when to escalate from agent to human. Designing workflows where humans and agents collaborate.

This is a new management skill. And it is not taught in any MBA program yet.

2. The “should we build an agent?” question is coming to your desk.

Within the next 12 months, someone in your organization will propose building an AI agent for a business process. Customer support. Lead qualification. Internal IT helpdesk. Employee onboarding. Expense report processing.

You will need to evaluate the proposal. Is this the right use case? Is the process repeatable enough for an agent? What are the failure modes? What happens when the agent makes a mistake? What data does the agent need access to? What are the security implications? What is the cost-benefit analysis?

These are management questions, not technical questions. And the manager who can answer them will be the one making the decisions. The manager who cannot will be the one nodding along in the meeting while someone else decides.

The honest risks you need to understand

AI agents are powerful. They are not perfect. Knowing the risks is as important as knowing the capabilities.

Risk 1: Agents fail silently. An agent can return a plausible, well-formed response that is completely wrong for the situation. No error is thrown. No alert fires. Nothing in the logs indicates a problem. Traditional software fails loudly. A server crash triggers an alert. An API error returns a code. Agent failures are different. The system looks healthy. The output is wrong. You only find out when a customer complains or a process breaks downstream.

Risk 2: Agents need guardrails. An agent with access to your email, calendar and CRM can do a lot of good. It can also send an embarassing email to a client, delete a calendar event, or update a CRM record incorrectly. Permissions and boundaries matter. What can the agent access? What actions can it take without approval? What requires human review? These guardrails must be defined before deployment, not discovered after a mistake.

Risk 3: Agents amplify bad data. An agent operating on inaccurate CRM data will make inaccurate decisions at scale. A customer’s address is wrong? The agent ships to the wrong location. A product price is outdated? The agent quotes the wrong price. Agents do not question data. They act on it. If the data is wrong, the actions are wrong. It matters at scale of thousands of interactions.

Risk 4: The accountability question. When a human employee makes a mistake, accountability is clear. When an AI agent makes a mistake, who is responsible? The manager who deployed it? The team that built it? The vendor who sold it? This question is not fully resolved in most organizations. And it matters because agents will make mistakes. Defining accountability before the mistake happens is a management responsibility.

A simple framework to evaluate any AI agent opportunity

When someone proposes an AI agent for your team, ask these five questions.

Agents are a new category of digital worker that can plan, execute, observe and adjust without waiting for your next message.

The companies deploying agents today — Salesforce, Shopify, Github, are not experimenting with a trend. They are building the operating model that every company will run within three years.

The manager who understands agents will design hybrid teams, define agent boundaries and make resourcing decisions that blend human judgment with machine execution.

The manager who does not will watch someone else make those decisions for them.

The shift from chatbots to agents is not coming. It is here.

If you like this article, you will absolutely love our AI Program Management Course ( having real AI PM Interview Questions from Google, OpenAI, Anthropic, Amazon etc) — ( 32+ Videos ) & ( Extra 25+ Real Case studies as well )

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

This question, or a version of it, now shows up in interviews for Program Managers, Product Managers, Business Analysts, Ops Managers and Strategy leads. Because every company is building AI features.

And every manager involved in those programs needs to understand how AI products are actually built.

The interviewer is not expecting you to Design a Neural Network. They are testing whether you understand the end-to-end journey of an AI feature.

From raw data to a live product serving millions of customers because if you are going to manage, consult on or make business decisions about AI programs, you need to know what happens behind the scenes.

Most candidates stumble here. They describe the user experience. They talk about the business value. They mention “Machine Learning” once and then skip to launch metrics. There is a massive gap in the middle where the actual AI work happens. The interviewer finds that gap. The interview ends poorly.

The ML Product Lifecycle fills that gap. Six stages. Each one has decisions that any manager needs to understand.

Let me walk you through the entire answer.

First, understand the feature

Before touching the lifecycle, make sure you understand what Complete the Look actually does.

You are shopping for a navy blue blazer on Amazon. Below the product, you see a section called “Complete the Look.” It shows you a white dress shirt, grey trousers, a brown leather belt, and oxford shoes. Not random products. A coordinated outfit. Items that go together visually and stylistically.

This is not “customers also bought.” That is collaborative filtering based on purchase behaviour. Complete the Look is visual and stylistic. It understands that a navy blazer pairs with grey trousers and brown shoes, not because other customers bought them together, but because they look good together.

This distinction matters in the interview. If you confuse Complete the Look with “Frequently bought together,” the interviewer knows you do not understand the ML problem.

Complete the Look is fundamentally a visual compatibility problem. The model needs to understand what items look like, what styles are compatible and what combinations create a cohesive outfit.

Now let us build it. Stage by stage.

Stage 1: Data Collection

Every AI feature starts with data. The first question any manager working on an AI program must answer is: what data do we need and where does it come from?

For Complete the Look, you need three types of data.

Product images. High-resolution images of every fashion item in Amazon’s catalog. The AI model will learn visual features from these images. Colour, pattern, texture, silhouette, material appearance. Without high-quality images, the model cannot perceive what the product looks like.

Amazon already has millions of product images. But not all are usable. Some are low resolution. Some have cluttered backgrounds. Some show the product at unusual angles. The manager needs to understand that “we have the data” and “we have usable data” are very different statements.

Outfit data. The model needs examples of what “goes together” looks like. Where does this come from?

Fashion editorial content. Magazines and lookbooks publish curated outfits. These are expert-labeled examples. A stylist chose that shirt to go with that blazer. That is a training signal.

User behavior data. When a customer buys a blazer and trousers in the same session, that is a weak signal of compatibility. When thousands of customers buy the same combination, the signal strengthens.

Social media. Instagram outfit posts. Pinterest boards. These are publicly available examples of outfits real people put together.

Product metadata. Category (shirt, trousers, shoes). Colour. Brand. Material. Season. Gender. Price range. This structured data supplements the visual data. The model should not recommend a winter coat to complete a summer dress look.

Why this matters for any manager

If you are a program manager, you are planning the timeline and coordinating teams. Understanding the data collection phase tells you that this is not a two-week sprint. It is a multi-month data acquisition effort with dependencies on image quality, external data sources, and cross-team coordination.

If you are a consultant advising a retail client on AI, you need to tell them the truth: the model is only as good as the data. If they do not have clean product images and labeled outfit data, no amount of engineering will produce good recommendations.

If you are a business leader evaluating this initiative, you need to ask: do we have the data? What does it cost to acquire what we are missing? How long does data collection take? Budget 30–40% of the total program timeline for data work. If anyone budgets 10%, the program will slip.

Stage 2: Data Cleaning and Preprocessing

Raw data is messy. Always. The manager who assumes “we have millions of images so we are fine” has never shipped an AI product.

Image cleaning. Remove low-resolution images. Remove images with watermarks or promotional overlays. Standardise image sizes. Normalise backgrounds.

Metadata cleaning. Product categories on any e-commerce platform are inconsistent. A “blazer” might be categorised as “jacket,” “sportcoat,” or “outerwear” depending on the seller. Colours might be listed as “navy,” “dark blue,” or “midnight” for the same shade.

This matters because a model trained on inconsistent data produces inconsistent recommendations. If “navy” and “dark blue” are treated as different colors, the model might recommend a navy blazer with dark blue trousers. They are essentially the same color and would clash visually.

Why this matters for any manager

This stage is where most AI programs die quietly. Not with a dramatic failure. With slow, invisible data quality problems that degrade model performance.

The Program Manager needs to budget real time for this. It is unglamorous. Nobody gets promoted for cleaning data. But without it, everything downstream breaks.

The consultant needs to flag this risk early. “Does your data team have a cleaning and standardisation process?” If the answer is vague, the project is in trouble before it starts.

The business leader needs to understand that “We have data” is not the same as “We have clean data.” The gap between the two is weeks or months of work.

Stage 3: Data Labeling

The model needs to learn what “goes together” means. To learn this, it needs labeled examples. Pairs of items explicitly marked as compatible or incompatible.

This is the most expensive and time-consuming stage. And it is where management decisions have the biggest impact on model quality.

Positive pairs. “This blazer goes with these trousers.” Each pair teaches the model what compatibility looks like.

Negative pairs. “This formal dress does not go with these slippers.” The model needs to learn what clashes too.

Who does the labeling:

Professional stylists. Highest quality. Most expensive. Slowest.

Trained annotators with fashion guidelines. Mid-quality. Faster. Cheaper. Quality depends entirely on the guidelines you write.

Crowdsourcing. Lowest cost. Highest volume. Most noise. You need multiple people labeling each pair and majority voting to filter errors.

Why this matters for any manager

The labeling guidelines are a business decision, not a technical one. What makes two items “compatible?” Should the model match price ranges? A $30 t-shirt with a $2,000 suit? Should it respect brand aesthetics? Should seasonal compatability matter?

The manager writes these rules. Or at least approves them. The rules determine what the model learns. Wrong rules produce a technically functional model that makes recommendations no customer wants.

For the program manager, this stage has the longest lead time. Labeling tens of thousands of pairs takes weeks. It is a dependency for everything downstream. Plan around it.

For the consultant advising on this project, the labeling strategy is the single biggest controllable variable in model quality. Push the client to invest here. Skimping on labeling is the fastest way to build AI that looks good in a demo and fails in production.

Stage 4: ML Model Training

Now the data is clean, labeled, and ready. The engineering team trains the model.

For Complete the Look, the model is a visual compatibility model. It processes product images through a neural network and produces numerical representations called embeddings. Items that are stylistically compatible end up “close” together in the embedding space. Items that clash end up “far” apart.

The manager does not design the neural network. That is the ML engineer’s job. But the manager needs to understand three things.

What compute is required. Training a visual model on millions of images requires GPUs. This has cost and timeline implications.

How long training takes. Model training is iterative. Train. Evaluate. Adjust. Retrain. Each cycle takes days or weeks. Plan for multiple cycles, not one.

What success looks like. This is the critical management decision. Define the success metrics before training starts.

Compatibility accuracy: What percentage of recommended pairs are genuinely compatible?
Diversity: Does the model recommend varied items or the same style repeatedly?
Coverage: What percentage of the catalog can the model generate recommendations for?
Latency: How fast does the model return results?

If you define success after seeing the results, you will move the goalposts to match whatever the model produced. Define it upfront. Hold the team to it. This is a management discipline, not a technical one.

Stage 5: ML Model Fine-Tuning

The initial model will not be good enough. It never is. Fine-tuning adjusts the model to improve performance where it is weak.

Common issues:

Color sensitivity. The model might recommend navy with black because they are visually similar in embedding space. But navy and black together is a fashion mistake. The model needs to distinguish between “visually similar” and “stylistically compatible.”

Category confusion. The model might recommend two pairs of shoes to complete a look. It needs to understand that a complete outfit needs one item from each category. One top. One bottom. One pair of shoes. Not three tops.

Price mismatches. A technically compatible recommendation is useless if it pairs a $20 t-shirt with $500 trousers.

Why this matters for any manager

The fine-tuning stage is where timeline pressure collides with quality ambition.

The jump from 70% to 85% accuracy might take two weeks. From 85% to 90% might take six weeks. From 90% to 95% might take three months.

For the Program Manager, this is the stage where stakeholders start asking “Why is this taking so long?” The answer is diminishing returns. Each percentage point of improvement costs more time than the last. The Program Manager needs to set these expectations early. Not when the team misses a deadline before the deadline is set.

For the Consultant, this is where you add the most value. Helping the client understand that AI quality is a spectrum, not a binary. And that the business case determines where on the spectrum they should aim.

Stage 6: ML Model Deployed Into Production

The model is trained, fine-tuned and meets the success criteria. Now it goes live.

This is where most Non-technical Managers think the job is done. For AI Programs, this is where a new phase begins.

Serving infrastructure. The model needs to generate recommendations in real-time. A customer looks at a blazer. The Complete the Look section needs to load in under 200 milliseconds. Any slower and the customer has scrolled past.

A/B testing. Before rolling out to all customers, run the feature on 10% of traffic. Measure engagement, click-through rate, add-to-cart rate and revenue per session. Compare against the control group. The manager defines the success metrics for the test. Not just “Did people click?” but “Did people buy?”

Monitoring. Once deployed, model performance must be tracked continuously. Fashion trends change. New products are added daily. A model trained on last season’s data will produce outdated recommendations this season. This is called model drift. It is not a bug. It is a certainty. The only question is whether anyone notices before customers do.

Retraining cadence. The manager defines how often the model gets retrained. Monthly? Quarterly? Triggered by performance drop? This is an ongoing operational commitment, not a one-time project decision.

Feedback loops. Which recommendations did customers click? Which did they buy? Which did they ignore? This behavioural data feeds back into the training pipeline. The model improves over time because it learns from real customer behaviour.

Why this matters for any manager

The deployment phase is where AI programs differ most from traditional software. In traditional software, you ship and maintain. In AI, you ship and continuously improve. The model is a living system. It degrades if you ignore it.

The Program Manager needs to plan for post-launch operations. Monitoring dashboards. Retraining pipelines. Incident response for when the model starts producing bad recommendations. This is not a project. It is a product that needs ongoing investment.

The business leader needs to budget for ongoing model operations. The launch cost is the beginning, not the end. Compute for retraining. Human evaluators for quality checks. Engineering time for monitoring and improvements. If the budget assumes “build once, run forever,” the feature will degrade within months.

The framework applied to your interview

Here is how to use this in any manager-level interview. Not just product management but any role where you might work on, manage or advise on AI programs.

Step 1: Clarify the feature. Show you understand what the AI is actually doing. Not the UI. The model.

Step 2: Walk through all six stages in order. Data Collection. Data Cleaning. Data Labeling. Model Training. Fine-Tuning. Deployment.

Step 3: At each stage, describe the key decision a manager makes. Not the engineering work. The management decision. What data to prioritise. How clean is clean enough. Who labels and by what rules. What success looks like. When to stop fine-tuning. How to test and monitor in production.

Step 4: Show you understand that deployment is not the end. Monitoring, retraining and feedback loops are ongoing. The AI feature is a living system, not a shipped feature.

This structure works for any AI feature question. Swap Complete the Look for “Build a fraud detection system” or “Design AI-powered demand forecasting” or “Create a personalized email recommendation engine.” The six stages are the same. The management decisions at each stage are the same.

The one thing to remember

The ML Product Lifecycle has six stages. Data Collection. Data Cleaning. Data Labelling. Model Training. Fine-Tuning. Deployment.

You do not need to build the model. You need to understand the decisions at every stage that determine whether the model succeeds or fails.

What data to collect. How clean is clean enough. Who labels and by what rules. What success looks like before training starts. When to stop fine-tuning. How to monitor after launch.

These decisions are management decisions. Not engineering decisions. The candidates who walk through all six stages with specific, thoughtful decisions at each one are the candidates who get offers. Regardless of whether the role is PM, Program Manager, Consultant or Business/Strategy leader.

If you like this article, you will absolutely love our AI Program Management Course ( having real AI PM Interview Questions from Google, OpenAI, Anthropic, Amazon etc) — ( 32+ Videos ) & ( Extra 25+ Real Case studies as well )

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Role. Task. Context. Format. Constraints.

You have stopped asking vague questions and started giving structured instructions.

Your output is better. Noticeably better.

But there is a ceiling. And you have probably felt it.

The output is good. Not great. Correct but predictable. Useful but generic. It does the job but it does not surprise you. You read it and think “this is fine” but never “this is exactly what I needed.”

That ceiling exists because good prompts tell the AI what to do. Great prompts tell the AI how to think.

There are three techniques that break through this ceiling. They are not hacks. They are not tricks. They are structural changes in how you communicate with the model that fundamentally alter how the model processes your request.

→ Chain-of-thought prompting
→ Few-shot prompting
→ Role-based prompting

Each one is simple to learn, takes 30 seconds to apply, and produces a measurable improvement in output quality. Let us go through them one at a time with examples you can use today.

Technique 1: Chain-of-Thought Prompting

The problem it solves

Ask ChatGPT a question that requires reasoning and it often jumps straight to the answer. No working shown. No logic visible. Just a confident conclusion.

Sometimes the conclusion is right. Sometimes it is wrong. And when it is wrong, you have no way of knowing where the reasoning broke down because there was no visible reasoning to examine.

This is like asking a colleague for a recommendation and they say “go with Option B” without explaining why. Maybe Option B is right. But you cannot evaluate the recommendation because you cannot see the thinking behind it.

Chain-of-thought prompting fixes this by asking the model to show its work.

How it works

You add one simple instruction to your prompt: “Think through this step by step.”

That is it. The impact is disproportionate to the effort.

When you ask the model to think step by step, it does not just produce an answer. It produces the reasoning that leads to the answer. Each step builds on the previous one. The logic is visible. You can follow it. You can spot where the reasoning is strong and where it is weak. You can correct specific steps without starting over.

Example without chain-of-thought

Prompt: “Should our company launch a premium tier for our SaaS product?”

AI output: “Yes, launching a premium tier could be beneficial. It would allow you to capture more value from power users, increase average revenue per user and create upsell opportunities. Consider adding advanced features, priority support, and higher usage limits.”

This answer is not wrong. It is also not useful. It skips the reasoning and jumps to a generic recommendation that could apply to any SaaS product on earth.

Example with chain-of-thought

Prompt: “Should our company launch a premium tier for our SaaS product? Think through this step by step. Consider the market signals, the risks, the pricing implications and the operational requirements before giving a recommendation.”

AI output:

“Step 1: Market signals. The question is whether there is a segment of users who need more than what the current plan offers and are willing to pay for it. Check your usage data. Are there users consistently hitting limits? Are there feature requests from high-value accounts that do not fit the current tier? If yes, demand exists.

Step 2: Revenue analysis. A premium tier only works if the price increase justifies the additional cost to serve. If premium features require significantly more compute, storage, or support, the margin may be thin. Calculate the incremental cost of each premium feature against the incremental revenue per user.

Step 3: Cannibalization risk. Will existing users downgrade their perception of the current plan? If the premium tier gets all the best features, the standard plan starts to feel like the ‘cheap’ option. This can increase churn at the lower tier even as it adds revenue at the upper tier.

Step 4: Operational complexity. A second tier means different support expectations, different feature access, different billing logic, and different onboarding flows. Does your team have the capacity to manage this complexity without degrading the experience for either tier?

Step 5: Recommendation. Based on these factors, a premium tier makes sense IF usage data shows a clear segment hitting limits, IF the margin math works, and IF your team can handle the operational complexity. If any of these conditions are not met, consider alternative approaches like add-on features or usage-based pricing instead of a full tier.”

Same question. Dramatically different output. The second response gives you a thinking framework, not just an answer. You can evaluate each step independently. You can push back on Step 3 if cannibalization is not a concern in your market. You can add data to Step 1 and ask the model to refine its recommendation.

When to use chain-of-thought

Any time the task requires reasoning, analysis, or decision-making. Strategy questions. Business cases. Problem diagnosis. Trade-off evaluation. Risk assessment.

Do not use it for simple factual questions or straightforward writing tasks. “What is the capital of France?” does not need step-by-step reasoning. “Write a meeting agenda” does not need it either. Use chain-of-thought when the quality of the thinking matters as much as the quality of the output.

The phrases that trigger it

“Think through this step by step.” “Break down your reasoning before giving a recommendation.” “Show your working. Walk me through how you arrived at this conclusion.” “Consider the following factors one at a time: [list factors].” “Before answering, analyze the pros and cons systematically.”

Any of these will activate the chain-of-thought pattern. Use the one that feels most natural to you.

Technique 2: Few-Shot Prompting

The problem it solves

You tell the AI what you want. It produces something in the right direction but the wrong format, the wrong tone or the wrong level of detail. You try again. Closer but still not right. You try a third time. Still off.

The problem is not that the AI cannot produce what you want. The problem is that words are imprecise. “Write a concise executive summary” means something different to you than it does to the model. “Concise” to you might mean 100 words. “Concise” to the model might mean 300 words. “Executive” to you might mean sharp, direct, and numbers-driven. “Executive” to the model might mean formal, hedging, and full of qualifiers.

Few-shot prompting solves this by showing the model what you want instead of telling it.

How it works

Instead of describing the desired output in words, you give the model one or more examples of the exact output you want. The model pattern-matches against the examples and produces something that follows the same structure, tone and format.

“Few-shot” means you provide a few examples (shots) before asking for the actual output. One example is “one-shot.” Two or three examples is “few-shot.” Zero examples is “zero-shot” which is what most people do by default.

Example without few-shot

Prompt: “Write a one-paragraph summary of our Q1 product launch for the leadership team.”

AI output: “In Q1, we successfully launched the new personalization engine, which represents a significant milestone in our product roadmap. The launch was completed on schedule and within budget, with initial metrics showing promising user engagement. The team demonstrated exceptional collaboration across engineering, design, and product management functions, and we look forward to building on this momentum in Q2.”

Corporate fluff. Says nothing specific. Could describe any launch at any company. The leadership team reads this and learns nothing they did not already know.

Example with few-shot

Prompt: “Write a one-paragraph summary of our Q1 product launch for the leadership team. Match the style and specificity of this example:

EXAMPLE: ‘Checkout redesign shipped Feb 12, two weeks ahead of schedule. Conversion rate moved from 3.2% to 4.1% in the first 30 days. Mobile conversion improved more than desktop (32% vs 18% lift). One open issue: page load time increased by 400ms on low-bandwidth connections. Fix is scoped for Sprint 14.’

Now write the summary for our personalization engine launch.”

AI output: “Personalization engine shipped March 8, on schedule. Click-through rate on recommended products moved from 2.1% to 3.8% in the first three weeks. Revenue per session increased 14% for logged-in users. Cold-start problem persists for new users with no browsing history. Mitigation plan using category-level defaults is in development, targeting Sprint 16.”

The second output has the same density, the same specificity, and the same structure as the example. The model did not need you to explain what “concise and specific” means. It saw what “concise and specific” looks like.

When to use few-shot

Any time the format, tone or structure of the output matters and you struggle to describe it in words. Which is most of the time.

Use it for email templates, status updates, slide content, social media posts, documentation, client communications and any recurring deliverable where consistency matters.

The power of few-shot increases with repetition. If you write weekly status updates, give the model one great example from a previous week. Every future status update will match that quality without you describing the format every time.

How many examples to give

One example is usually enough for format and structure. The model picks up the pattern quickly.

Two examples are better when there is variety within the pattern. “Here is an example of a positive update and here is an example of an update that flags a risk.”

Three examples are the maximum. Beyond three, you are consuming tokens without improving output quality. The model has already learned the pattern.

Technique 3: Role-Based Prompting

The problem it solves

The AI defaults to “generic helpful assistant.” It tries to be useful to everyone. The result is output that is helpful to no one in particular.

When you ask for strategic advice, it gives you a balanced overview instead of a sharp recommendation. When you ask for feedback on your writing, it tells you everything is “well-structured” instead of pointing out that paragraph three is redundant. When you ask for a client email, it sounds like a chatbot instead of a senior professional.

The AI is holding back. Not because it cannot be sharper. Because its default persona is designed to be safe, balanced, and inoffensive.

Role-based prompting overrides this default by assigning the AI a specific identity with specific expertise and specific communication standards.

How it works

You tell the model who it is before telling it what to do. The role activates the relevant patterns from the model’s training data. When the model “is” a McKinsey partner, it draws from patterns it learned from consulting language, strategic frameworks, and executive communication. When it “is” a CFO, it draws from financial analysis patterns, risk language, and board-level communication.

The role is not a costume. It is a filter. It determines which subset of the model’s vast knowledge is activated for this conversation.

Example without role

Prompt: “Review my project proposal and give feedback.”

AI output: “Your proposal is well-structured and covers the key points effectively. The objectives are clear and the timeline is reasonable. You might consider adding more detail to the risk section and expanding on the budget breakdown. Overall, it is a solid proposal.”

This feedback is useless. Everything is “solid” and “well-structured.” The AI is being polite. Polite feedback does not improve proposals.

Example with role

Prompt: “You are a senior partner at a top consulting firm. You have reviewed hundreds of project proposals. You are known for being direct, specific, and constructive. You do not say ‘good job’ unless the work is genuinely exceptional. Review my project proposal. Point out the three biggest weaknesses and suggest specific improvements for each.”

AI output:

“Three issues.

First, your problem statement is buried in paragraph two. The reader should know what problem you are solving within the first two sentences. Move it up. Make it the opening line. Right now, I have to read 150 words before I understand why this project exists.

Second, your ROI projection has no assumptions listed. You claim 25% efficiency improvement but you do not say how you arrived at that number. Without visible assumptions, the number looks invented. Add the calculation. Show the baseline, the expected change, and the driver behind the change.

Third, your risk section lists risks but no mitigations. ‘Vendor dependency is a risk’ tells leadership nothing they do not already know. What are you doing about it? Add a mitigation for each risk or remove the risk section entirely. A risk without a mitigation is just a worry.”

Same proposal. Same AI. The role changed the output from polite generalities to actionable specifics. The model is not being rude. It is being the person you asked it to be. A senior partner who has reviewed hundreds of proposals and does not waste time on pleasantries.

The roles that work best

The most effective roles have three components. A seniority level. A domain. And a communication style.

“You are a senior supply chain consultant who specializes in last-mile logistics. You communicate in short, direct sentences with specific recommendations. You do not hedge.”

“You are a CFO at a mid-size SaaS company. You evaluate everything through the lens of unit economics, cash flow, and payback period. You ask tough questions.”

“You are a seasoned program manager who has shipped AI products at scale. You focus on risks, dependancies, and what could go wrong that nobody is talking about.”

Each role produces a fundamentally different output from the same prompt. The supply chain consultant gives operational advice. The CFO gives financial scrutiny. The program manager gives risk analysis.

The role determines the lens. The lens determines the output.

Combining all three techniques

The real power comes from combining these techniques in a single prompt. Here is what that looks like.

Combined prompt:

“You are a senior management consultant who advises mid-market retail companies on digital transformation. You are direct, data-driven, and allergic to vague recommendations. [ROLE]

Here is an example of the analysis format I want: [paste one example of a previous analysis]. [FEW-SHOT]

A retail client with 200 stores is considering implementing AI-powered demand forecasting. They currently use spreadsheet-based forecasting which takes their planning team 3 days per cycle. They have 2 years of clean sales data. Their biggest pain point is overstocking seasonal items.

Think through this step by step. Consider the feasibility, the expected ROI, the implementation risks, and the organizational change required before giving your recommendation. [CHAIN-OF-THOUGHT]”

This prompt uses all three techniques. The role sets the lens. The few-shot example sets the format. The chain-of-thought instruction sets the reasoning depth. The output from this prompt will be dramatically more useful than any single technique alone.

The one thing to remember from today

Good prompts tell the AI what to do. Great prompts tell the AI how to think, what good output looks like, and who to be while producing it.

Three techniques. Chain-of-thought shows the reasoning. Few-shot shows the format. Role-based sets the expertise.

Each one takes 30 seconds to add to your prompt. Each one produces a measurable jump in output quality. Combine all three and you are operating at a level that most AI users will never reach.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Subscribe now

Same consultant. Same domain expertise. Same client. Add AI to the workflow and both quality and speed jump simultaneously.

That does not happen with any other productivity tool.

→ A better laptop does not make your analysis 40% sharper.
→ A faster internet connection does not make your recommendations 25% more useful.

AI does something different. It does not just speed up your existing workflow. It changes what one person can produce.

This is the shift. Not “AI helps consultants work faster.” That is the small version. The real version is this

AI is creating a new type of consultant. One who operates at the output level of a small team, at the cost structure of a solo practitioner, with the quality of a seasoned expert.

This is the AI-augmented consultant. And the operating model behind it is what we are breaking down today.

You can also become an AI-augmented consultant → https://topmate.io/technomanagers/new/QEFtA3GQ7y

The 60/40 problem that AI solves

Let me start with the ugly truth about consulting work.

If you are a consultant, roughly 40% of your week is spent on the actual work clients pay for. The thinking. The analysis. The strategy. The frameworks. The recommendations. The judgment calls that come from years of domain expertise.

The other 60% is spent on everything around the work. Research. Data gathering. Slide formatting. Proposal drafting. Meeting notes. Status updates. Email follow-ups. Invoice processing & Scheduling.

That 60% is not value-added work. It is necessary work. It has to get done. But no client has ever paid a premium because your meeting notes were well-formatted or your proposal used the right font.

The traditional consulting model solved this problem with people. Junior analysts did the research. Associates built the slides. Support staff handled the invoice. Partners did the thinking. The pyramid existed to separate the 40% that required judgment from the 60% that required labor.

AI eliminates the pyramid by eliminating the 60%.

Not some of it. Not the easy parts. Nearly all of it.

Research that used to take a junior analyst two days? Perplexity and Claude synthesise it in 15 minutes. Slide decks that used to consume an entire evening? Google Slides powered by Gemini and Canva AI produce a first draft in seconds. Meeting notes that used to take 30 minutes to write up? Microsoft CoPilot captures, transcribes, and summarises in real-time. Proposals that used to take a full day? Claude drafts a client-ready version in 20 minutes with the right context.

The math is simple. If AI handles 60% of your week, you have reclaimed 24 hours. You can use those hours for more client work (more revenue) or deeper thinking (better quality) or both.

The consultants who figured this out are billing more, delivering faster, and producing higher quality work than consultants who are still doing everything manually. The gap is not closing. It is widening every month.

The new operating model in five layers

The AI-augmented consultant does not just add AI tools to their existing workflow. They rebuild the workflow from scratch. Here is the operating model.

Layer 1: The knowledge base. AI that remembers everything you know.

Every consultant accumulates intellectual capital over their career. Frameworks. Methodologies. Client insights. Industry knowledge. Case study patterns. Best practices.

In the traditional model, this knowledge lives in scattered documents, old presentations, and the consultant’s memory. It is disorganised, hard to search, and impossible to reuse efficiently.

In the AI-augmented model, this knowledge is centralised in an AI-accessible system.

Claude Projects lets you upload your entire library of frameworks, past deliverables, methodology documents, and industry research. Every conversation within that Project has access to everything. When you ask Claude to draft a competitive analysis, it does not start from zero. It starts from your accumulated knowledge.

NotebookLM lets you upload 50 documents and have a conversation with all of them simultaneously. Upload every past project report for a specific industry. Ask “What are the three most common recommendations I have made to retail clients?” It reads all 50 documents and synthesises the answer.

McKinsey’s built in-house generative AI platform, Lilli, with access to over 100 years of the firm’s institutional knowledge, case files and research.

The consultant who has their knowledge organised in an AI-accessible system can retrieve, reuse, and recombine their past work in seconds. The consultant who searches through old folders and emails for 30 minutes every time they need a past framework is operating at a fraction of the speed.

Layer 2: The research engine. AI that gathers faster than a team.

Client research. Market sizing. Competitive landscapes. Industry trends. Regulatory analysis. Due diligence.

This used to be the work that justified hiring junior team members. Spend two days in databases, reports, and industry publications. Compile findings. Format into a readable deliverable. Present to the senior consultant.

The AI-augmented consultant does this differently.

Start with Perplexity for broad research with cited sources. It searches the web, synthesizes findings, and provides links to every source. You get a researched overview in 3 minutes instead of 3 hours.

Move to Claude or ChatGPT for deep analysis. Paste the raw research. Ask for structured analysis. “Identify the top five trends, the three biggest risks, and the one contrarian insight most analysts are missing.” The AI processes the information and produces the analytical layer.

Use ChatGPT’s Code Interpreter for data analysis. Upload the dataset. Ask for correlations, visualisations, and statistical summaries. Work that used to require an analyst with Excel skills now happens in a conversation.

The research output of one consultant with AI is comparable to the research output of a three-person team without AI. Not identical. The human team brings judgment and intuition that AI cannot replicate. But for the gathering, organising, and initial analysis phases, AI matches or exceeds human speed at a fraction of the cost.

Layer 3: The production engine. AI that builds deliverables.

This is where the operating model delivers its most visible impact. The actual deliverables. Slides, documents, proposals, reports and client communications.

The old model: spend 6 hours building a 30-slide deck. 2 hours on content. 4 hours on formatting, alignment, and making it look professional.

The AI-augmented model: spend 20 minutes giving Claude the context, the structure and the style constraints. Get a first draft. Spend 40 minutes refining it with your judgment, your client-specific insights and your recommendations. Use Google Slides powered by Gemini or Canva AI for the visual layer.

Total time: 1 hour instead of 6. And the output is arguably better because you spent 40 minutes on the thinking instead of 4 hours on the formatting.

The same applies to proposals. A Statement of Work that used to take a full day now takes 90 minutes. A client email that used to take 20 minutes of careful wordsmithing now takes 5 minutes of review. A project status report that used to take Friday afternoon now takes 10 minutes of editing an AI-generated draft.

The production bottleneck that has constrained solo consultants since forever is gone. You are no longer limited by how fast you can build. You are limited only by how fast you can think.

Layer 4: The client intelligence layer. AI that understands each client.

This is the layer most consultants have not built yet. And it is the one that creates the strongest competitive advantage.

For every active client, build a dedicated AI context. In Claude Projects, create a project for each client. Upload everything. Their strategy documents. Past deliverables. Meeting transcripts. Email threads. Industry reports. Competitive data.

Now when you need to prepare for a client meeting, you do not re-read 30 documents. You ask Claude “What were the three key decisions from our last four meetings with ABC Corp and what is still unresolved?” Claude reads everything and gives you a briefing in seconds.

When you need to write a recommendation, you do not start from a blank page. You ask Claude “Based on everything we know about ABC’s supply chain challenges, what are the three highest-impact interventions we should recommend?” Claude generates recommendations grounded in the actual client context. Your job is to apply judgment, prioritize, and add the insights that only come from being in the room with the client.

This is not replacing the consultant. This is giving the consultant an associate who has read every document, remembers every conversation and is avaliable 24 hours a day.

The consulting firms charge premium rates because they have institutonal knowledge. Lilli at McKinsey, Deckster at BCG. The AI-augmented solo consultant can build their own version of this. Not at the same scale. But at a scale that is good enough for most client engagements.

Layer 5: The pricing shift. From hours to outcomes.

This is the layer that turns the operating model into a business model.

The traditional consulting pricing model is time-based. Hourly rates. Day rates. Retainers based on expected hours. This model made sense when the consultant’s output was constrained by their available hours. More hours, more output, more revenue.

AI breaks this model.

When AI compresses a 6-hour deliverable into 1 hour, the time-based consultant faces a choice. Bill for 1 hour (and take a massive revenue cut). Or bill for 6 hours (and feel dishonest about charging for time not spent). Neither option works.

The AI-augmented consultant switches to outcome-based pricing. You charge for the deliverable, not the hours. A competitive analysis is worth $5,000 to the client regardless of whether it took you 6 hours or 1 hour to produce. A strategy recommendation that saves the client $2 million is worth $50,000 regardless of how many meetings it took to develop.

Outcome-based pricing captures the value AI creates instead of penalizing the consultant for being efficient. The consultant earns more per engagement. The client pays for results, not time. Both sides win.

The data supports this. DEMG’s analysis shows that consulting practices that transition to outcome-based pricing see exit multiples rise from 4x toward 6x EBITDA. The business itself becomes more valuable because revenue is tied to impact, not to a finite number of billable hours.

The competitive math that should keep every traditional consultant up at night

Here is the math.

A traditional solo consultant works 40 billable hours per week. They spend 60% on non-value-added work. That leaves 16 hours of actual thinking and strategy. They bill by the hour. Revenue is capped by available hours.

An AI-augmented solo consultant works 40 hours per week. AI handles 60% of the non-value-added work. That frees up 24 hours. They now have 40 hours of thinking time instead of 16. They bill by the outcome. Revenue is capped by the number of clients they can serve well, not by available hours.

The AI-augmented consultant can serve 2–3x more clients at the same quality level. Or serve the same number of clients at dramatically higher quality because they are spending 40 hours thinking instead of 16.

Either way, the traditional consultant cannot compete. Not on speed. Not on price. Not on output volume. The only dimension where the traditional consultant can compete is relationship depth and domain expertise. And those advantages erode the moment the AI-augmented consultant has the same relationships and the same expertise plus the AI leverage.

What to do starting this week

The operating model is not something you build in a weekend. It is something you build in layers over 8–12 weeks. Here is the sequence.

Week 1–2: Build your knowledge base. Pick Claude Projects or NotebookLM. Upload your top 20 frameworks, past deliverables, and methodology documents. Start every client conversation with this knowledge accessible to the AI.

Week 3–4: Automate your meeting workflow. Start using Microsoft CoPilot in Teams or Otter.AI for every meeting. Let AI handle transcription, summaries and action items. Review and send. Never write meeting notes manually again.

Week 5–6: Rebuild your deliverable production process. For every slide deck, proposal and report, start with an AI first draft. Give it your style profile, your client context and your structural requirements. Spend your time refining, not building.

Week 7–8: Build client-specific AI contexts. For your top three clients, create dedicated Claude Projects with all relevant documents. Start using the AI as a client intelligence tool, not just a writing tool.

Week 9–12: Shift your pricing. For new engagements, experiment with outcome-based pricing. Price the deliverable, not the hours. Track the impact on your revenue per engagement and your total capacity.

If you follow this sequence, you will have a functioning AI-augmented operating model within 90 days. Not a perfect one. A functional one that you can refine over time.

I have been writing about this transformation in my 100-day bootcamp on The AI Professional. If you want a structured, daily guide to building AI fluency as a consultant or business professional, that is exactly what the bootcamp is designed for. Every day covers one concept, one framework, or one practical skill. No code. No jargon. Just the operating model, built one layer at a time.

The one thing to remember from today

The consulting industry is splitting into two groups.

Group 1 uses AI as a side tool. They paste a prompt into ChatGPT occasionally. They use it for quick drafts. Their operating model is unchanged. Their capacity is unchanged. Their pricing is unchanged.

Group 2 has rebuilt their entire operating model around AI. Their knowledge is AI-accessible. Their research is AI-accelerated. Their deliverables are AI-drafted and human-refined. Their client intelligence is AI-powered. Their pricing is outcome-based.

Group 1 is competing against Group 2 with 16 hours of thinking time per week versus 40. With 6-hour deliverables versus 1-hour deliverables.

The operating model is not optional. It is the new baseline.

And the consultants who build it first will be the ones who are still billing in 2028. The countdown has already started.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Subscribers )

2. Become AI Consultant or Business Manager

3. Become AI Program Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

There is a pattern in how program managers prepare for Technical Program Manager(TPM) roles.

They polish their Gantt chart skills. They update their resume with words like “Cross-functional leadership” and “Stakeholder Management.” They read a few articles about LLMs. They add “AI/ML program experience” to their LinkedIn headline.

Subscribe now

They think they are ready.

The job descriptions say otherwise.

I spent three weeks reading 50 Technical Program Manager job postings. Google, Amazon, Meta, Google DeepMind, Anthropic, Stripe, and a handful of AI-native startups.

I was looking for one thing. What skills are companies actually asking for versus what TPM candidates are actually building.

The gap is larger than I expected.

What everyone is preparing for

The standard AI TPM preparation list looks like this.

Learn how LLMs work at a surface level. Understand the basic ML lifecycle. Practice telling stories about cross-functional coordination. Highlight how you managed timelines and dependencies on complex programs.

This is not wrong. These things appear in JDs.

But they appear the same way “excellent communication skills” appears in a generic PM role basically as filters that remove clearly unqualified candidates. Not as signals that separate good candidates from great ones.

The companies I reviewed are past the point where “I managed a program that had an ML component” is a differentiator. They are hiring for people who have operated AI programs at the systems level. Operated at the intersection of engineering execution, ML uncertainty, and organizational complexity.

Three skills kept appearing across JDs in a way that most candidates are not building.

Skill 1: Technical Translation Under Pressure

Every TPM job description mentions cross-functional coordination. That is not news. TPMs have always coordinated across teams.

What is new is the specific type of translation AI programs demand.

In a traditional software program, the TPM coordinates between engineering, product, design, and QA. Everyone speaks roughly the same language. A “bug” means the same thing to everyone. A “feature” means the same thing. A “release” means the same thing. The TPM manages timelines and dependencies. The translation burden is low.

In an AI program, the translation burden is the job.

The ML engineer says “the model is overfitting on the training distribution and we need to regularise.” The data engineer says “the feature store latency is causing training-serving skew.” The product manager says “the user experience is inconsistent and we are getting negative feedback.” The VP says “Why is this taking so long?”

All four people are describing the same problem. None of them know it.

The ML engineer is seeing the problem in model metrics. The data engineer is seeing it in infrastructure. The product manager is seeing it in user behaviour. The VP is seeing it in the timeline.

The TPM who can connect these four perspectives, who can say “the inconsistent user experience is caused by training-serving skew, which is caused by feature store latency, which will require a two-week infrastructure fix before model retraining will improve the product metrics” is the TPM who unblocks the program.

The TPM who takes notes and schedules a follow-up meeting is the TPM who adds a week of delay.

This is not generic “communication skills.” This is real-time technical translation under organisational pressure. It requires deep enough technical understanding to parse what each team is saying, broad enough organisational awareness to connect their perspectives, and fast enough synthesis to do it in the room, not in a follow-up document.

Google’s TPM job posting for AI Enablement says it explicitly. “Use leadership, product, and technical judgment in AI to drive program delivery.” Technical judgment in AI. Not technical awareness. Judgment. The ability to hear a technical statement and know whether it is a real blocker or a solvable problem, whether the timeline impact is two days or two months, and whether the team needs more resources or a different approach.

Amazon’s Principal TPM posting for AI agent integration asks the candidate to “guide architectural decisions and establish engineering standards.” Not relay architectural decisions from engineers but guide them. The TPM is expected to be in the room where technical choices are made, contributing to those choices, not just documenting them.

How this shows up in interviews:

“Your ML team says they need three more weeks for model training. What do you do?”

A weak answer: “I would update the timeline, communicate the delay to stakeholders, and schedule a check-in with the ML team.”

A strong answer: “I would first understand why. Is it the data pipeline, the compute capacity, the model architecture, or the evaluation criteria? If it is data quality, I need the data engineering team in the room immediately because that is an upstream dependency. If it is compute, I can potentially accelerate by requesting additional GPU allocation. If it is the architecture, three weeks might be optimistic and I need to reset expectations now rather than face a second delay later. The conversation with stakeholders changes completely depending on the root cause.”

The first answer manages a schedule. The second answer manages a program. The JDs are looking for the second.

Real AI Program Manager Interview Questions (with Detailed Solutions)

Skill 2: Navigating ML Uncertainty in Program Planning

This is the biggest gap between traditional TPMs and AI TPMs. And it is the skill that most candidates do not realise they lack until they are in the interview.

Traditional software programs are deterministic. You build a feature. It works or it does not. You test it. It passes or it fails. The scope is defined. The effort is estimable. The timeline has unknowns, but they are manageable unknowns. Delays come from dependencies, resource constraints, or scope changes. All of these are familiar.

AI programs are probabilistic. The model might not work. You will not know until you try. The team might run five experiments before finding an approach that meets the quality bar. Each experiment takes two weeks. You cannot skip the experiments. You cannot parallelize them because each one depends on the learnings from the previous one.

How do you build a program plan around that?

This is the question that separates AI TPMs from traditional TPMs. And the JDs are testing for it explicitly.

The answer involves three planning frameworks that appeared repeatedly across the JDs I reviewed.

Framework 1: Milestone-based planning instead of task-based planning.

In AI programs, you cannot plan around tasks because you do not know which tasks will exist until experiments reveal the viable approach. Instead, you plan around quality milestones. “Model accuracy exceeds 85% on the evaluation set.” “End-to-end latency is below 200ms at p99.” “Hallucination rate is below 2% on the golden test set.”

The milestone is a quality gate, not a calendar date. The team works toward the milestone. When they hit it, they move to the next phase. If they do not hit it, you do not pretend they did. You adjust.

Framework 2: Experiment budgets with explicit failure rates.

“We have a two-week experiment budget to test three retrieval approaches. We expect one or two to fail. The surviving approach moves to the build phase.”

This framing does two things. It sets realistic expectations with stakeholders. Experimentation is not a delay. It is a planned phase with a planned duration and a planned failure rate. And it gives the team psychological safety to try approaches that might not work, which is how breakthroughs happen.

Framework 3: Parallel workstreams with convergence gates.

Data preparation, model development, and infrastructure setup can often run in parallel. But they must converge at defined checkpoints where you verify that everything fits together. The data pipeline feeds the right format to the model. The model output is compatible with the serving infrastructure. The evaluation metrics are being tracked end-to-end.

The TPM designs these convergence gates. Nobody else will. The ML team is focused on the model. The infra team is focused on the platform. The data team is focused on the pipeline. Only the TPM sees the full picture and owns the integration points.

How this shows up in interviews:

“The product team wants to launch an AI feature in 8 weeks. The ML team says they need 14 weeks for proper evaluation. How do you handle this?”

A weak answer: “I would find a compromise timeline.”

A strong answer: “First, I would break down the 14 weeks. What specific phases are included? Is it 4 weeks for data preparation, 4 weeks for experimentation, 3 weeks for training and evaluation, and 3 weeks for integration testing? If so, I can potentially overlap data preparation with infrastructure setup. I can define clear experiment budget boundaries so experimentation does not expand indefinitely. I can identify which evaluation criteria are launch-blocking and which can be monitored post-launch. The goal is not to compress 14 weeks into 8. The goal is to identify the minimum viable scope that meets the quality bar within a timeline both teams can commit to. If 8 weeks is genuinely not feasible without unacceptable quality risk, I need to escalate that trade-off to leadership with data, not just a request for more time.”

Skill 3: Owning the AI Reliability Stack

Traditional TPMs own the delivery. Ship the feature. Hit the date. Move to the next project.

AI TPMs own the reliability. Because in AI programs, shipping is not the end. It is the beginning of the hardest phase.

Models degrade over time. Data distributions shift. User behavior changes. A model that performs at 92% accuracy at launch might drop to 78% three months later because the world changed and the model did not. This is called model drift. It is not a bug. It is a certainty. The only question is when it happens and whether anyone notices before customers do.

The JDs I reviewed have a consistent expectation. The AI TPM owns the post-launch reliability of the AI system. Not just the monitoring dashboards. The entire operational stack.

This includes five specific responsibilities that appeared repeatedly.

Evaluation frameworks. How do you know the model is good enough? Not once. Continuously. The TPM defines the eval strategy. Which metrics. What thresholds. How often. Who reviews failures. When to retrain. When to roll back.

The OpenAI CPO said at Lenny’s podcast conference in 2025: “The most important thing a product manager can learn to do is write evals.” This applies equally to TPMs. A TPM who cannot define what “good enough” looks like for an AI system cannot manage one.

Cost monitoring. Every AI query costs money. The TPM needs to track cost per query, project costs at scale, and flag when a feature’s compute costs are growing faster than its revenue contribution. A feature that works beautifully but costs $15 million a day in compute is not a successful launch. It is a financial crisis.

Latency and performance. AI features often have hard latency requirements. A recommendation system that takes 3 seconds to respond degrades the user experience worse than showing no recommendations at all. The TPM owns the latency budget. How much time does the model get? How much for the API call? How much for the front-end rendering? When the total exceeds the budget, who is responsible for optimization?

Incident response for AI failures. When the model starts hallucinating in production, who gets paged? What is the escalation path? What is the rollback procedure? Is there a fallback to a rule-based system? Can you disable the AI feature without taking down the entire product?

Traditional incident response is built for deterministic failures. The server crashed. The database is down. The API is returning errors. AI failures are different. The system is technically up. The API is responding. But the responses are wrong. Or biased. Or dangerous. The system looks healthy from every infrastructure metric. The failure is in the output quality, not the system availability.

The TPM who has a playbook for this is the TPM who gets hired.

Retraining cadence. How often does the model need to be retrained? What triggers a retrain? Is it calendar-based (every 30 days) or performance-based (when accuracy drops below a threshold)? Who owns the retraining pipeline? What is the rollback process if the new model is worse than the old one?

How this shows up in interviews:

“You launched an AI feature last quarter. Accuracy has dropped from 91% to 82%. Walk me through your next 48 hours.”

A weak answer: “I would alert the ML team and ask them to investigate.”

A strong answer: “First, I would check whether the drop is global or segment-specific. If it is limited to one user segment or one geography, the cause is likely a data distribution shift in that segment. If it is global, the cause is likely broader. Second, I would check when the drop started and what changed. Was there a data pipeline update? A model retrain? A feature store change? Third, I would assess severity. Is 82% below our launch-blocking threshold? If yes, I would activate the rollback plan to the previous model version while the team investigates. If it is above the threshold but trending downward, I would set a 48-hour investigation window with daily syncs. Fourth, I would notify stakeholders proactively with a clear status: what happened, what we know, what we are doing, and when we will have an update.”

What this means for your preparation

The JDs are not asking for people who know about AI programs. There are thousands of those.

They are asking for people who have operated AI programs. Who have made technical translation calls under pressure. Who have built program plans around ML uncertainty. Who have owned the reliability of a live AI system in production.

These are three specific skills.

Technical translation. Not “I communicate well across teams.” But “I can hear an ML engineer describe a training-serving skew problem and translate it into a business impact statement for the VP in real-time.”

ML uncertainty planning. Not “I managed a program with an AI component.” But “I designed experiment budgets, quality-gated milestones, and convergence checkpoints that let the team explore uncertain approaches without blowing up the timeline.”

AI reliability ownership. Not “I shipped the feature.” But “I owned the evals, the cost monitoring, the latency budget, the incident response plan, and the retraining cadence after launch.”

If you are preparing for an AI TPM role right now, stop spending time on generic program management storytelling. Start spending time on these three skills.

This might help you to prepare in detail about Evals

Understand how experiments are planned in ML teams. Study post-launch monitoring for AI systems. Build a point of view on how AI programs should be planned differently from traditional software programs.

The candidates who can articulate these three skills with real examples are the candidates who get offers. The JDs are very clear about which one they want.

A quick self-assessment

Ask yourself these five questions. Be honest.

1. Can you explain the difference between training-serving skew, model drift, and data poisoning in one sentence each?

2. Can you design a program plan for a project where the ML team needs to run experiments before committing to an approach?

3. Can you define evaluation criteria for an AI feature that go beyond accuracy and include cost, latency, fairness, and failure modes?

4. Can you describe what a rollback plan looks like for an AI model in production?

5. Can you explain to a VP why an AI project that is “80% done” might still be 6 weeks from launch?

If you answered yes to all five, you are ready.

If you answered no to two or more, you now know exactly where to focus.

The role is evolving fast. The TPMs who evolve with it will manage the most important programs at the most important companies. The ones who do not will manage programs that could have been managed by a Gantt chart and a weekly email.

The JDs are clear. The question is whether you are building what they are asking for.

For Program Managers and TPMs looking for a deeper dive into AI Program Management with real interview preparation, check out the AI Program Manager course.

30+ videos with real AI PM interview questions from Google, Netflix, Meta, Amazon, and AI startups.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Subscribe now

In 2023, McKinsey built an AI tool and named it Lilli.

Lilli has access to 100 years of McKinsey’s intellectual property. Over 100,000 documents and interviews. Every framework, every case study, every research report the firm has ever produced.

Ask Lilli a question. It searches the entire knowledge base in seconds. It summarizes the key points. It identifies five to seven relevant internal documents. It points you to the specific experts inside the firm who know the most about your topic. It drafts slide decks. It writes research summaries. It does analysis.

Today, over 75% of McKinsey’s employees use Lilli. The heavy users open it around 17 times a week. McKinsey’s own case study reports a 30% time savings for consultants using the tool.

Here is the number that should make every consultant pay attention.

One industry analysis estimated that tools like Lilli could already perform roughly 80% of a junior analyst’s typical research and slide-generation work in seconds. Work that used to take a new hire an entire week.

This is not a future projection. This is happening now. And it is not just McKinsey. Every major consulting firm has built its own version. The entire industry is rebuilding itself around AI. And the changes go far deeper than faster Power Points.

Today we go inside the consulting AI revolution. What the firms actually built. How they use it. And what it means for anyone who works in consulting or wants to.

The proprietary AI assistant is now table stakes

Here is the first thing to understand. Every major consulting firm has built its own internal AI assistant. Not bought. Built. Or at least heavily customized on top of commercial models.

McKinsey has Lilli. BCG has Deckster and a broader internal platform. Deloitte has PairD and DARTbot. Bain has Sage. EY has EYQ. PwC has ChatPwC. KPMG has Workbench. Accenture has its own suite.

They all deployed on essentially the same timeline between 2023 to 2024. They all serve tens of thousands of consultants. They are all built on GPT-4-class models with the firm’s proprietary knowledge layered on top.

This tells us something important. When every competitor in an industry builds the same capability at the same time, that capability is no longer a differentiator. It is a baseline. A consulting firm without an internal AI assistant in 2026 is like a consulting firm without email in 2006. The tool itself is not the advantage. It is the price of staying in the game.

The real differentiation has moved elsewhere. To how well consultants use the tools. To what proprietary data the firm feeds the AI. To how deeply the AI is integrated into the actual work.

What these tools actually do

Let us be specific about the work AI is doing inside consulting firms right now.

Knowledge retrieval and synthesis

This is the foundational use case. Consulting firms sit on enormous knowledge bases. Decades of client work, frameworks, research and case studies. The problem was always access. A consultant in Mumbai could not easily find the relevant work a colleague did in London few years ago.

Lilli solves this with RAG - Retrieval Augmented Generation. The exact technology you learned about on Day 5. When a consultant asks Lilli a question, it does not generate an answer from a general model. It first retrieves relevant documents from McKinsey’s proprietary knowledge base, then synthesies an answer grounded in the firm’s actual intellectual property.

This is RAG deployed at the highest level of professional services. The consultant gets an answer that reflects 100 years of McKinsey thinking, not a generic response from a public model. The knowledge that used to be locked in scattered documents and individual experts’ heads is now instantly accessible to every consultant in the firm.

Slide deck creation

This is the use case that gets the most attention because slides are the core deliverable of consulting.

BCG built a tool called Deckster. It automatically polishes PowerPoint presentations, dramatically reducing the time consultants spend on formatting. A consultant produces the content. Deckster handles the visual polish that used to consume hours of manual work.

McKinsey’s Lilli drafts entire slide decks on demand. Describe what you need. Lilli produces a structured first draft. The consultant refines it instead of building it from scratch.

This matters because slide creation was historically one of the most time-consuming and least valuable parts of consulting work. Junior consultants spent late nights formatting boxes, aligning text, and adjusting colours. AI has compressed that work from hours to minutes.

Research and analysis

What used to be a week-long research assignment for a new hire can now often be done by AI in minutes. Market sizing. Competitive landscape analysis. Industry trend research. Literature reviews. Data summarisation.

The AI does not replace the thinking. It replaces the gathering. The consultant still decides what questions to ask, how to interpret the findings, and what recommendations to make. But the grunt work of collecting and organising information has been automated.

Proposal and content writing

Deloitte has experimented with GPT-based tools to write proposals and even code for clients. The first draft of a proposal, a statement of work, or a client communication can now be AI-generated and then refined by the consultant.

The number that should concern every junior consultant

Here is where the story gets serious.

When Lilli launched in 2023, McKinsey cut over 5,000 jobs the same year. The firm has not directly attributed these cuts to AI. But the timing and the trend across the industry tell a clear story.

The Big Four firms have significantly dialed back entry-level hiring. KPMG slashed hiring for entry-level jobs by 29%. Deloitte by 18%. EY by 11%. In the UK, job board data shows 44% fewer openings for accounting graduates compared to 2023.

The reason is structural. The traditional consulting model was a pyramid. A large base of junior analysts did the research, built the slides, and crunched the data. A smaller layer of managers directed the work. A thin layer of partners sold the work and managed client relationships.

The junior analyst layer existed to do the work that AI now does. Research. Slides. Data analysis. If AI can do 80% of that work in seconds, the firm needs fewer junior analysts.

“Why pay a team of fresh MBAs to sift through data and crank out PowerPoints when an AI can do it faster and cheaper?” That question is being asked in every consulting firm right now. And the answer is reshaping how many people the industry hires and what those people are expected to do.

This is the uncomfortable truth about AI in consulting. The tool that makes senior consultants more productive is the same tool that reduces the need for junior consultants. The efficiency gain and the job reduction are the same phenomenon viewed from two angles.

What this means if you work in consulting

The consulting career path is being rebuilt. Here is how to think about your position in it.

If you are a junior consultant or aspiring to be one the work that used to define your early years is being automated. You will not spend two years building slides and doing research to pay your dues. That work is largely gone.

This is not entirely bad news. The menial & tedious work that used to fill the first years is exactly the work nobody enjoyed. The opportunity is to move up the value chain faster. But only if you develop the skills that AI cannot replicate.

What AI cannot do: build client relationships, navigate organisational politics, exercise judgment in ambiguous situations, synthesize insights into genuinely novel strategy, and persuade a skeptical executive to act.

These are the skills that now matter from Day One. The firms are no longer hiring people to do mechanical work. They are hiring people who can do the judgment work that used to be reserved for senior consultants.

The bar has risen. A new consultant in 2026 is expected to operate at a level that would have taken two years to reach in 2020. AI handles the foundational work. You are expected to add value above it immediately.

Become an AI Consultant Today -> Link

If you are a mid-level or senior consultant

AI is a leverage multiplier for you. You can now do the work that used to require a team of junior analysts. One senior consultant with strong AI fluency can produce the output that used to require three or four people.

This is an opportunity and a threat. The opportunity: you can take on more clients, deliver faster, and increase your value to the firm. The threat: if you do not develop AI fluency, a peer who has will outperform you dramatically. The productivity gap between AI-fluent and AI-resistant consultants is not 10%. It is multiples.

The senior consultants who thrive in this environment are the ones who treat AI as a junior team member that works instantly, never sleeps, and costs almost nothing. They delegate the research, the first drafts, and the analysis to AI. They focus their own time on judgment, client relationships, and strategic synthesis.

If you are an independent consultant or want to be

This is the most exciting shift. AI has dramatically lowered the barrier to operating as an independent consultant.

Historically, you could not compete with McKinsey because you did not have a team of analysts, a vast knowledge base, or the production capacity to deliver polished work at scale. AI changes the equation. A skilled independent consultant with AI tools can now produce research, analysis, and deliverables at a quality and speed that used to require a team.

You will not match McKinsey’s brand or its century of proprietary knowledge. But for many clients, especially mid-market companies, an experienced independent consultant augmented by AI offers comparable quality at a fraction of the cost. The consulting market is opening up to solo operators in a way it never has before.

The framework consulting firms use that you can steal

Here is the most valuable part of this article. The big firms have developed a way of thinking about AI integration that any professional can adopt.

McKinsey calls its approach “Rewired.” It defines six capabilities that leaders must build to make AI transformation real. The framework was designed for client engagements, but it works for individual professionals and any organization.

One. A roadmap tied to real value. Do not adopt AI for its own sake. Identify the specific high-value work where AI creates measurable improvement. Start there.

Two. A bench of skilled people. AI fluency is a skill that must be developed. McKinsey discovered that its consultants faced “prompt anxiety” when Lilli launched. One hour of prompt training dramatically increased adoption. The lesson: training matters more than tools. A great tool with untrained users produces nothing.

Three. An operating model that moves fast. Build processes that let AI integrate into actual workflows, not sit on the side as an experiment.

Four. A flexible technology environment. Do not lock into one model. McKinsey works with an ecosystem of 19 AI companies. The flexibility to use the best tool for each task matters.

Five. Data embedded throughout. The AI is only as good as the data it can access. McKinsey’s advantage is not the model. It is the 100 years of proprietary knowledge layered on top of the model.

Six. Adoption that converts to gains. A tool that people do not use creates zero value. The entire game is adoption. 75% of McKinsey using Lilli 17 times a week is the metric that matters, not the existence of Lilli.

The lesson for any professional: the firms that win with AI are not the ones with the best models. They are the ones with the best adoption, the best training, and the best proprietary data. The model is a commodity. Everything around it is the advantage.

The honest caveat the firms learned the hard way

AI in consulting is not flawless. And the firms have the scars to prove it.

Deloitte was asked to issue a partial refund for a report prepared for the Australian government. The reason? The $440,000 (AUD) report contained AI-generated hallucinations. Citations to sources that did not exist. The exact failure mode you learned about on Day 7.

This is the cautionary tale. AI accelerates the work. But it does not remove the responsibility to verify. A consultant who submits AI-generated work without checking it is not being efficient. They are being reckless. The Deloitte incident is a costly lesson in why the verification framework from Day 7 is not optional.

The firms that use AI well have built verification into their process. AI drafts. Humans verify. AI accelerates. Humans remain accountable. The moment a firm forgets this, it ends up issuing refunds and apologizing to clients.

The one thing to remember from today

The biggest consulting firms in the world have spent over $10 billion building AI into their core operations. They have automated roughly 80% of the work that junior consultants used to do. They have cut entry-level hiring. They have rebuilt the consulting pyramid.

This is not a trend to watch. It is a transformation that has already happened.

If you work in consulting, the message is clear. The mechanical work is gone. The judgment work is everything. Develop the skills AI cannot replicate. Build AI fluency that lets you operate at the level of an entire team. And never submit AI-generated work without verifying it, unless you want to write a $440,000 (AUD) refund check.

The consultants who treat AI as a threat will be replaced by consultants who treat AI as leverage. Same tool. Opposite outcomes. The difference is whether you learn to use it before it learns to do your job.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

New ones launch every day. Product Hunt features five AI products every morning. LinkedIn influencers post “10 AI tools that will change your life” every afternoon. Your inbox has at least three newsletters telling you about AI tools you have never heard of.

The result is not excitement. It is paralysis.

Most professionals open one of these lists, scan 30 tool names they have never seen, feel vaguely guilty about being behind, and close the tab. Nothing changes. They go back to using ChatGPT for everything because at least they know how that works.

Here is the truth that none of those lists will tell you.

There are only 5 categories of AI tools. Every tool on every list you have ever seen fits into one of these five categories. The categories have not changed since 2023. They will not change in 2027. The tools within each category change constantly. The categories themselves are stable.

Once you understand the five categories, three things happen. You stop feeling overwhelmed because the landscape suddenly has structure. You stop wasting time evaluating tools that solve problems you do not have. And you start building a personal AI stack that covers your actual needs with the minimum number of tools.

Five categories. That is the entire map.

Category 1: Thinking Tools. AI that helps you reason.

This is the foundational category. Every professional needs at least one thinking tool. Most already have one and do not realize they are underusing it.

Thinking tools are large language models with a chat interface. You give them a problem. They help you think through it. You give them information. They help you make sense of it. You give them a question. They help you explore the answer from multiple angles.

What they do: Answer questions. Explain concepts. Brainstorm ideas. Analyze documents. Summarize research. Compare options. Write drafts. Debug logic. Challenge your reasoning. Simulate perspectives.

The tools: ChatGPT. Claude. Gemini. Perplexity. These four cover 95% of what any professional needs in the thinking category.

Let’s see which model excels at what. Claude for writing and long documents. ChatGPT for data analysis and quick tasks. Gemini for research with current information and Google Workspace integration. Perplexity for research with source citations.

Why this category matters most: The thinking tool is the one you will use 10 times a day. It replaces the moments where you used to stare at a blank screen, Google something for 20 minutes, or ask a colleague a question you felt embarrassed asking. A thinking tool gives you an always-available, judgment-free, infinitely patient partner for working through any professional problem.

The mistake most professionals make: Using the thinking tool as a search engine. Typing short, vague queries. Getting generic answers. Thinking the tool is not that useful. The thinking tool is a reasoning partner. It gets better as you give it more context, more constraints, and more specific instructions. Everything from Days 8 and 9 of this bootcamp applies here.

Category 2: Writing Tools. AI that helps you communicate.

This is the category where AI delivers the most immediate time savings for the most professionals. Because every professional writes. Emails. Reports. Proposals. Slack messages. Status updates. Presentations. Documentation.

Writing tools fall into two sub-categories.

General writing assistants that draft content from scratch. The thinking tools from Category 1 can all do this. But some professionals prefer dedicated writing environments.

Jasper (for marketing copy). Copy.ai (for short-form content). Writesonic (for blog posts and ads). These are wrappers on top of the same foundation models, but with templates, brand voice settings and workflow features designed specifically for content production.

Editing and enhancement tools that improve what you have already written.

Grammarly is the dominant tool here. It lives inside your browser, your email client, and your document editor. It catches grammar errors, suggests clarity improvements, adjusts tone, and rewrites sentences. It works everywhere you type.

Hemingway Editor highlights complex sentences, passive voice, and readability issues. It does not rewrite for you. It shows you where your writing is hard to read and lets you fix it.

Why this category matters: Writing is the single largest time investment most professionals make after meetings. A tool that reduces writing time by 50% returns hours per week. Not in theory. In practice.

The mistake most professionals make: Using writing tools without giving them a style profile. The output sounds generic because the tool does not know how you write. Go back to Day 9. Run the mirror technique. Save your style profile. Paste it every time. The output transforms from “sounds like a robot” to “sounds like a better version of me.”

What to avoid: Do not pay for a dedicated AI writing tool if you already have a ChatGPT or Claude subscription. The writing capability in your thinking tool is usually as good as or better than standalone writing tools that charge extra. The standalone tools justify their price only if you need specific features like brand voice memory, team collaboration or template libraries.

Category 3: Creation Tools. AI that helps you make things.

This is the category that gets the most attention and the most hype. AI that creates images, videos, audio, presentations, and designs.

Image generation. Midjourney, DALL-E (inside ChatGPT), Adobe Firefly, Ideogram. You describe an image. The AI creates it. Midjourney produces the highest quality artistic output. DALL-E is the most convenient (built into ChatGPT). Ideogram is the best at rendering text within images. Adobe Firefly integrates with Photoshop and Illustrator for professionals already in the Adobe ecosystem.

Video generation. Runway, Pika, HeyGen. Runway creates short video clips from text or images. HeyGen creates AI avatar videos and can translate existing video into different languages with lip-synced dubbing. This category is evolving the fastest and is still early. Quality is improving month over month.

Audio and voice. ElevenLabs for voice generation and text-to-speech. Descript for audio and video editing with AI-powered transcription, overdub, and filler-word removal. Descript is particularly useful for professionals who record meetings, create podcasts, or produce training content.

Design. Canva has integrated AI deeply into its platform. AI-powered background removal, text-to-image, magic resize, and content suggestions. For non-designers, Canva with AI is the only design tool they will ever need.

Why this category matters: Creation used to require specialized skills. Graphic design. Video production. Audio engineering. AI has compressed the skill requirement. A program manager can now create a client presentation with custom visuals, a consultant can produce a polished report with original graphics, and a marketing lead can generate campaign assets without a design team.

The mistake most professionals make: Spending too much time in this category. Creation tools are seductive. Generating images is fun. Making presentations is satisfying. But unless creation is your core job function, these tools should be occasional productivity boosters, not daily time sinks. A consultant who spends 2 hours perfecting a Midjourney image for a slide deck instead of 10 minutes finding a stock photo has lost the productivity plot.

What to budget: Midjourney is $10–30 per month. Canva Pro is $13 per month. Gamma has a free tier. Most professionals need at most two tools from this category. Canva for everyday design. One image generator for occasional custom visuals.

Category 4: Automation Tools. AI that does repetitive work for you.

This is the category that delivers the highest long-term ROI. Not the highest immediate gratification (that is Category 3). The highest sustained value over months and years.

Automation tools connect your apps and workflows. They watch for triggers and execute actions. When a specific event happens, the tool automatically performs a sequence of steps without you lifting a finger.

Zapier is the market leader. It connects over 7,000 apps. “When I receive an email with an attachment, save the attachment to Google Drive, summarize the email with AI, and add a task to my project board.” That is one Zapier automation. It runs every time you receive an email with an attachment. Forever. Without you doing anything.

Make (formerly Integromat) is the power-user alternative. More complex workflows. More control over branching logic. Visual workflow builder. Steeper learning curve but more flexibility.

n8n is the open-source option. Self-hosted. Free. Highly customizable. Best for teams with technical capability who want full control over their automation infrastructure.

Microsoft Power Automate is the choice for organizations deep in the Microsoft ecosystem. It integrates natively with Outlook, Teams, SharePoint and the entire Microsoft 365 suite.

The AI layer in these tools has changed the game. In 2024, you needed to know exactly what you wanted automated and how. In 2026, you can describe what you want in natural language. “Every Friday, summarize my unread Slack messages from the #project-atlas channel, identify any action items, and send me an email with the summary and action list.” Zapier’s AI builds the automation for you.

Why this category matters: The first three categories save minutes per task. Automation saves hours per week. Because it does not just speed up a task. It eliminates the task entirely. You never do it again. The automation runs in the background while you sleep, eat, and work on things that actually require your brain.

The mistake most professionals make: Not starting. Automation has a setup cost. You spend 30 minutes building the automation. Then it saves you 5 minutes a day for the rest of the year. The math is overwhelmingly positive. But the 30 minutes of setup feels harder than the 5 minutes of daily drudgery. This is a psychological barrier, not a logical one.

Where to start: Pick the one task you do every single day that follows the same steps every time. Email sorting. Meeting note distribution. Status report compilation. Data entry. File organization. Automate that one task. Experience the feeling of it running without you. Then automate the next one.

Category 5: Knowledge Tools. AI that organizes what you know.

This is the most underused category. And in many ways, the most transformative.

Knowledge tools use AI to organize, search, and surface information across your documents, notes, files, and conversations. They solve the problem every professional has but rarely articulates: “I know I have this information somewhere. I just cannot find it.”

Notion AI turns your Notion workspace into a searchable, AI-powered knowledge base. Ask questions across all your notes, documents, and databases. “What were the key decisions from last month’s product reviews?” Notion AI searches your workspace and synthesizes the answer.

Mem is a note-taking tool built around AI from the ground up. It auto-organizes your notes, surfaces related information, and generates insights across your entire note history.

Google’s NotebookLM lets you upload documents and have conversations with them. Upload 10 research papers. Ask “What do these papers collectively say about the impact of AI on supply chain efficiency?” NotebookLM reads all 10 and synthesizes the answer with citations.

Microsoft Copilot embedded in Microsoft 365 acts as a knowledge tool across your entire Microsoft ecosystem. It searches your emails, documents, Teams conversations, and SharePoint files to answer questions and generate content based on your organization’s information.

Perplexity functions as a knowledge tool for external information. It searches the web, synthesizes findings from multiple sources, and provides cited answers.

Why this category matters: Every professional has a personal knowledge management problem. Years of documents, notes, emails, and files scattered across multiple platforms. The information exists. Finding it takes longer than recreating it from scratch. Knowledge tools solve this by making your existing information searchable and synthesizable.

The real power: Knowledge tools become exponentially more useful over time. The more information you put into them, the more connections they can surface, the more questions they can answer, and the more value they provide. A Notion workspace with three months of meeting notes, project documents, and decision logs becomes a personal institutional memory that no amount of manual filing can match.

The mistake most professionals make: Not feeding the system. A knowledge tool is only as good as the information it has access to. If you take notes in one app, store documents in another, and have conversations in a third, no single knowledge tool can connect them. Pick one system. Centralize your professional knowledge there. Let the AI do the organizing.

The minimum viable AI stack

You do not need 10 tools. You do not need 20. You need three to five.

Here is the minimum stack that covers all five categories for most professionals.

One thinking tool with writing capability. Claude or ChatGPT. This covers Category 1 and most of Category 2.

One editing tool. Grammarly. This covers the rest of Category 2. Lives in your browser. Works everywhere you type. Free tier is sufficient.

One creation tool. Canva with AI. This covers most of Category 3 for non-designers. Add Midjourney only if you regularly need custom images.

One automation tool. Zapier. This covers Category 4. Free tier to start.

One knowledge tool. Notion AI or NotebookLM. This covers Category 5. NotebookLM is free.

The one thing to remember from today

10,000 AI tools exist. They fall into 5 categories.

Thinking. Writing. Creation. Automation. Knowledge.

You do not need to evaluate 10,000 tools. You need to pick one strong tool in each category that matters for your work. Three tools minimum. Five tools maximum. That covers your entire professional AI surface.

The professionals who are most productive with AI are not the ones who use the most tools. They are the ones who use the right tools deeply. One good thinking tool used with strong prompts beats 10 mediocre tools used with vague queries.

Build your stack. Learn your tools. Go deep, not wide.

Tomorrow we look at how specific industries are using AI right now.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Question: You are managing an AI-powered demand forecasting program. The model needs retraining every 2 weeks as new sales data comes in. Your engineering team runs 2-week sprints. How do you structure the program?

The issue is that candidates immediately start talking about sprint planning. The real problem is deeper.

Model retraining is not a feature. It is an operational loop that runs in parallel to feature development.

If you put retraining inside the sprint, it eats 30–40% of engineering capacity every cycle. If you put it outside the sprint, there is no accountability.

The core problem

Model retraining is not a feature. It is not a user story. It is not something you estimate in story points and slot into a sprint.

Model retraining runs in parallel to feature development. It has its own inputs (new data), its own success criteria (accuracy thresholds), and its own failure modes (data drift, pipeline failures, validation errors). None of these map to the sprint planning rituals that work for software delivery.

When you put retraining inside the sprint, one of two things happens.

Option one: Retraining eats 30 to 40 percent of engineering capacity every cycle. The team delivers fewer features. Leadership starts asking why velocity is dropping. The PgM scrambles to explain that the team is “also doing model work.” This explanation never lands well in a sprint review.

Option two: Retraining gets deprioritised because the feature backlog is louder. The model quietly degrades. Nobody notices until the demand forecast is off by 15 percent and the supply chain team is asking why inventory levels are wrong. By then, the retraining debt is 6 weeks deep.

Model retraining is NOT a sprint task. It is an operational loop

Both options are failure modes. The sprint was never designed to hold this.

Why sprints break for AI

The sprint framework was built for deterministic software delivery. You write a spec. You estimate effort. You build. You ship. The output is predictable. If you say “this feature will take 5 story points,” you are usually right within a reasonable margin.

Model retraining does not work this way.

You trigger the retraining pipeline. The pipeline runs. A new model is produced. But the new model might be worse than the old one. The accuracy might drop because the new data introduced a distribution shift. Or the accuracy holds on the validation set but degrades on a specific segment. Or the pipeline itself fails because the data schema changed upstream and nobody told the ML engineer.

None of these outcomes are predictable at sprint planning. You cannot estimate “retrain the model” as a 3-point story because the effort is fixed but the outcome is variable. The pipeline takes the same number of hours every time. What changes is whether the output is usable.

This is the fundamental mismatch. Sprints assume effort correlates with outcome. In model retraining, effort is constant and outcome is stochastic.

A recent analysis showed Model performance does not decay smoothly along a predictable curve. It switches. A new fraud pattern emerges overnight. A competitor exits the market and their customers arrive with different characteristics. A regulatory change alters the transaction mix. These are not points on a decay curve. They are regime changes that invalidate the model’s assumptions in a single day.

Demand forecasting has the same property. A sudden supply chain disruption, a competitor’s flash sale. The model does not degrade gracefully. It breaks.

You cannot sprint-plan for regime changes.

The Dual Cadence Framework

The fix is not to make sprints longer or to create “model sprints.” The fix is to stop pretending that feature development and model operations belong on the same cadence.

Here is the framework.

Cadence one: Feature development. This runs on the sprint. Two-week cycles. Backlog grooming. Sprint reviews. The usual. Every ticket in this cadence produces a deterministic output. A new UI component. A new API endpoint. A data pipeline enhancement. The PgM tracks velocity, scope, and timeline the way they always have.

Cadence two: Model operations. This runs on its own loop. The loop is triggered by time (every 2 weeks for the demand forecasting case), by data volume thresholds (retrain when N new records arrive), or by performance thresholds (retrain when accuracy drops below X). The loop has its own success criteria, its own tracking, and its own review cadence.

These are not two teams. This is one team with two workstreams. The same engineers might work on both. But the backlogs are separate. The success criteria are separate. The reporting is separate.

The reason this works is that it eliminates the competition between features and model health. Retraining is never deprioritized because it was never in the feature backlog to begin with. It sits in its own cadence with its own accountability structure.

Defining “retraining done”

The second part of the framework is redefining what “done” means for model retraining. In a sprint, done means the code is merged, tested, and deployed. Retraining done is fundamentally different.

Retraining is not done when the pipeline runs. It is done when three conditions are met.

Condition one: the new model’s primary metric is within the acceptable threshold. For demand forecasting, this is typically MAPE (mean absolute percentage error). If the current production model has a MAPE of 8 percent and the retrained model has a MAPE of 11 percent, retraining failed. The pipeline ran. The output is unusable.

Condition two: the new model has been validated against the holdout set AND against the production distribution. Holdout validation catches statistical errors. Production distribution validation catches segment-level regressions. A model can improve globally by 2 percent while degrading by 15 percent on your highest-revenue product category. Both validations are required.

Condition three: the new model has been deployed to shadow mode and its predictions have been compared against the production model for a defined window (typically 24 to 48 hours for demand forecasting). If shadow performance matches or exceeds production performance, the cutover happens. If not, the old model stays.

This changes how you track progress entirely. You do not track “retraining” as a task with a due date. You track it as a metric with a threshold. The dashboard shows: current model MAPE, retrained model MAPE, shadow comparison result, last successful cutover date. The PgM reviews this weekly. No sprint review needed.

The stakeholder communication problem

This is where most candidates lose the interview. And where most PgMs lose in practice.

You have separated the cadences. You have defined retraining done as a metric. The framework is clean. But now you need to explain this to your VP of Engineering, your product lead, and your business stakeholders. And from their perspective, the team’s feature velocity just dropped.

It did not drop. But it looks like it dropped because the team is now splitting time between two workstreams and only one of them shows up in the sprint review.

Here is how you handle this.

First, make the model operations cadence visible. Create a separate dashboard or a separate section in the program review that shows model health metrics, retraining history, and the impact of model improvements on business outcomes. If the demand forecast improved from 12 percent MAPE to 8 percent MAPE over the last quarter, that has a dollar value. Calculate it. Show it. Leadership cares about business impact. They do not care about pipeline runs.

Second, frame the dual cadence as risk management, not capacity allocation. The question is not “how much time are we spending on retraining?” The question is “what happens to the demand forecast if we skip retraining for 6 weeks?” If the answer is “MAPE degrades to 18 percent and inventory costs increase by $2M,” the dual cadence justifies itself.

Third, never present the two cadences as competing for the same resources. Present them as two investment categories with different return profiles. Feature development has a linear return (more features, more product capability). Model operations has a maintenance return (sustained accuracy, prevented degradation). Both are necessary. Neither is optional.

The capacity allocation question

The practical question every Program Manager faces: how much engineering time goes to each cadence?

There is no universal answer. But there is a framework for deciding.

Start with the retraining cost. How many engineer-hours does a single retraining cycle consume? For a mature pipeline with automation, the answer is often 4 to 8 hours of active engineering time per cycle. The pipeline runs for longer, but the engineer is not sitting and watching it.

Then calculate the feature development capacity. If you have 5 engineers at 40 hours per week, that is 200 hours per sprint. If retraining consumes 8 hours per sprint from one engineer, that is 4 percent of total capacity. Not 30 percent. Not 40 percent. Four percent.

The reason candidates say “30 to 40 percent” is that they are including debugging time for when retraining fails, ad-hoc model investigation, data quality firefighting, and pipeline maintenance. These are real costs. But they are not retraining costs. They are model operations costs. And they need to be tracked separately so the Program Manager knows where the time is actually going.

If model operations is consuming 30 percent of engineering capacity, the problem is not the dual cadence. The problem is pipeline reliability, data quality, or infrastructure maturity. Those are engineering problems with engineering solutions. The Program Manager’s job is to surface them, not to absorb them into the sprint.

What this changes for AI Program Manager interview prep

The reason this question separates candidates in Senior TPM is that it tests three things simultaneously.

It tests whether you understand that AI programs have a fundamentally different delivery structure than software programs.

It tests whether you can design an operational framework (dual cadence) and not just describe a process (sprint planning with model work added).

It tests whether you can communicate that framework to non-technical stakeholders without making it sound like the team is doing less work.

Most Program Manager interview prep focuses on the first two. The third one is where the offer is decided.

This article covers the concepts behind Module 7 (Program Execution and Delivery) and Module 10 (Domain and Metrics Execution) of the AI Program Management course. The full course covers 16 modules across 32 videos, including worked examples, frameworks, and mock interview walkthroughs.

Check out the Course: https://topmate.io/technomanagers/2033621

McDonald’s partnered with IBM for three years to build AI-powered drive-thru ordering. It tested the system at over 100 US locations. Social media filled with videos of confused customers watching the AI add 260 Chicken McNuggets to their order while they begged it to stop. McDonald’s shut the entire project down.

Humane raised $230 million. Built a team of ex-Apple engineers. Designed a wearable AI device that projected a laser display onto your palm. It was going to replace the smartphone.

It shipped fewer than 10,000 units. The company sold its assets for $116 million. Every device ever shipped was permanently bricked on February 28, 2025. Customers lost a $699 product that became a paperweight overnight.

Sora, the AI video generation tool, burned an estimated $15 million per day in compute costs. It generated $2.1 million in total lifetime revenue. The product shut down on April 26, 2026. Disney had committed $1 billion to a partnership that included Sora. Disney learned about the shutdown less than an hour before the public announcement.

Three products. Combined destruction of over billions in capital, trust, and market confidence. Each one had world-class talent. Each one had serious funding. Each one had massive initial excitement.

Each one failed because someone asked

“Can we use AI for this?”

instead of asking “Should we use AI for this?”

These are different questions. And the gap between them is where billions of dollars vanish.

Why “can we” is the wrong question

The AI industry has a seduction problem.

AI can do remarkable things. It can write. It can code. It can analyse data. It can generate images. It can process documents. It can hold conversations. Every month, the list of things AI can do gets longer.

And every month, more companies make the same mistake. They see a capability and immediately look for a place to deploy it. “AI can understand speech. Let us put it in our drive-thru.” “AI can generate video. Let us build a product around it.” “AI can answer questions. Let us replace our customer service team.”

This is technology-first thinking. Start with the technology. Find a problem to attach it to. Build the product. Launch. Discover that nobody needed it.

The opposite approach is problem-first thinking. Start with a real problem. Understand why it is painful. Understand what current solutions exist. Understand why they are insufficient. Then ask whether AI is the best way to solve it. Not the most impressive way. The best way.

Every failed AI product in the last two years shares one characteristic. The team started with the technology and worked backward to a problem. Every successful AI product shares the opposite characteristic. The team started with a problem and discovered that AI was the best solution.

This is not a difference in execution. It is a difference in thinking. And it happens before a single line of code is written.

The 7 situations where AI is the wrong answer

Here is the framework. Seven specific conditions where AI is likely the wrong solution. Each one is illustrated by a real product that failed because it ignored the condition.

Condition 1: When the non-AI solution already works well enough.

This is the most common and most ignored condition.

The failure: Humane AI Pin.

The Humane AI Pin tried to replace the smartphone. It offered voice-based AI interaction, a laser display projected onto your palm, and a camera for visual queries.

The problem? The smartphone already does all of this. And it does it better. With a screen you can actually read. With apps that actually work. With a battery that lasts all day. With an ecosystem of accessories and services built over 15 years.

The AI Pin was not solving a problem. It was offering a different solution to a problem that was already solved. And the different solution was worse on every measurable dimension. Smaller display. Shorter battery life. Fewer capabilities. Higher price.

When a non-AI solution already works well enough, AI does not just need to match it. AI needs to be dramatically better. Not 10% better. Dramatically better. Because switching costs are real. Habits are real. Ecosystem lock-in is real. Nobody switches from a good enough solution to a marginally different one, no matter how much AI is inside it.

The test: Ask yourself: what does the user currently use to solve this problem? If the answer is a product that works reasonably well, your AI solution needs to be 10x better, not 10% better. If it is not 10x better, it will not overcome the switching cost.

Condition 2: When the error cost is higher than the efficiency gain.

AI makes mistakes. Every AI system has a failure rate. The question is whether the cost of those failures exceeds the value of the successes.

The failure: McDonald’s AI drive-thru.

The AI-powered drive-thru was supposed to save labor costs and speed up ordering. Instead, it created viral videos of absurd errors. 260 Chicken McNuggets. Orders that could not be corrected. Customers screaming at a machine that could not understand them.

Each error had a real cost. Wasted food. Frustrated customers who might never return. Negative brand perception from millions of social media views. The efficiency gains from AI ordering were measured in seconds saved per transaction. The error costs were measured in lost customers and brand damage.

A wrong order at a drive-thru is not a small mistake. It is a customer experience failure at the exact moment of purchase. The customer is hungry, often in a hurry, and already committed to buying. Getting their order wrong does not just lose that transaction. It loses future transactions.

The test: Calculate the cost of AI getting it wrong. Not just the immediate cost. The downstream cost. Customer trust lost. Brand damage. Legal liability. Regulatory fines. If the cost of a single error exceeds the cumulative savings from a hundred successful interactions, AI is the wrong solution. Add a human in the loop.

Condition 3: When the unit economics do not work at scale.

AI is not free. Every AI query costs compute. The more users, the more queries, the more compute, the more cost. If the cost per query exceeds the revenue per query, the product loses money on every interaction. And it loses more money as it gets more popular.

The failure: Sora.

Sora generated AI video. It was technically impressive. Users loved it. It burned $15 million per day in compute costs. It generated $2.1 million in total lifetime revenue. Not per day. Total.

The math was structurally broken. Generating a single high-quality video required enormous computational resources. The price users were willing to pay could not cover the cost of generation. More users meant more losses. Success was financially catastrophic.

This is not a scaling problem that solves itself with growth. This is a unit economics problem. Each additional unit of usage makes the business worse, not better. No amount of marketing or distribution fixes negative unit economics.

The test: Calculate the cost per AI interaction. Calculate the revenue per interaction (directly or through subscription allocation). If cost exceeds revenue and there is no credible path to reducing cost below revenue within 18 months, the product is structurally unprofitable. Shipping it is burning money.

Condition 4: When the AI cannot reliably do what the demo showed.

This is the demo-to-production gap. The AI works brilliantly in a controlled demo. It fails unpredictably in the real world.

The failure: Rabbit R1.

The CES 2024 demo was magical. The device ordered an Uber, booked a restaurant, managed apps, and answered questions. It looked like the future.

The shipped product could do almost none of this. The “Large Action Model” that powered the demos could not reliably interact with real apps in real-world conditions. Apps change their interfaces. Authentication flows differ. Edge cases multiply. The controlled demo environment had none of these complications. The real world had all of them.

100,000 people bought the product based on the demo. Mass returns followed when the product could not deliver on its demo promises.

The test: Before committing resources to production, test the AI in conditions that match real-world use. Not cherry-picked scenarios. Not controlled environments. Messy, unpredictable, edge-case-heavy real conditions. If the AI’s reliability drops significantly from demo to real-world testing, the product is not ready. Shipping an unreliable product is worse than shipping nothing because it destroys trust that takes years to rebuild.

Condition 5: When the problem requires judgment, not prediction.

AI is excellent at prediction. It is terrible at judgment.

Prediction: What word comes next? What product will this customer buy? What is the probability of fraud? These are pattern-matching tasks. AI excels at them.

Judgment: Should we enter this market? Is this employee ready for a promotion? Should we settle this lawsuit? Is this the right time to acquire that company? These are decisions that require weighing values, understanding context, considering politics, and accepting responsibility for the outcome.

The failure: AI-powered hiring tools (HireVue and others).

HireVue used AI to analyze facial expressions, tone of voice, and word choice during video interviews. The AI scored candidates against an “ideal candidate” profile.

The fundamental problem? Hiring is a judgment task, not a prediction task. Whether someone will be a good employee depends on team dynamics, management style, cultural fit, growth potential, and dozens of other factors that cannot be captured by analyzing facial microexpressions.

The AI was predicting who looked like previous successful hires. It was not judging who would be the best fit for this specific role, on this specific team, at this specific point in the company’s evolution. The prediction was precise. The judgment was absent. The result was bias, discrimination lawsuits, and abandoned technology.

The test: Ask whether the decision requires weighing values and accepting responsibility. If yes, AI should inform the decision, not make it. Use AI to gather data, surface patterns, and present options. Keep the judgment with a human who can be accountable for the outcome.

Condition 6: When the trust requirement exceeds AI’s reliability.

Some tasks require near-perfect accuracy. Not 95%. Not 99%. Near-perfect.

The failure: New York City’s MyCity chatbot.

New York City launched an AI chatbot called MyCity to help entrepreneurs navigate business regulations. The chatbot told business owners they could take a cut of their workers’ tips. It said they could fire employees who complained about sexual harassment. It claimed landlords could discriminate based on source of income. It said restaurants could serve food that had been nibbled by rodents.

All of this was wrong. And all of it, if followed, would lead business owners to break the law.

The chatbot was 95% accurate on routine questions. But 5% error rate on legal guidance is catastrophic. A business owner who follows incorrect legal advice faces fines, lawsuits, and criminal liability. The city faces reputational damage and legal exposure.

In domains where trust is critical — legal, medical, financial, regulatory — AI’s current reliability is insufficient for autonomous operation. A 95% accuracy rate sounds good until you realize that 1 in 20 answers could destroy someone’s business, health, or freedom.

The test: Ask what happens if the AI gives wrong information and the user acts on it without checking. If the consequence is serious (legal liability, health risk, financial loss, safety hazard), the AI must not operate autonomously. It can assist. It can draft. It can suggest. A qualified human must review and approve before the information reaches the end user.

Condition 7: When AI is solving a problem that does not exist.

This is the most fundamental failure. The product works. The AI is reliable. The economics are sound. But nobody actually has the problem the product solves.

The failure: Most AI wrappers that shut down in 2025–2026.

40% of AI startups launched in 2024 shut down within 24 months. Not because the technology failed. Because the problem did not exist at sufficient scale to sustain a business.

AI-powered logo generators. AI resume writers. AI email assistants. AI meeting summarizers. Each one solved a real but tiny friction. A friction so small that users were not willing to pay for a standalone product to address it. When the same capability was added for free inside ChatGPT, Canva, Notion, or Gmail, the standalone product had no reason to exist.

The problem was not that the AI did not work. The problem was that the problem was not painful enough to justify a separate product, a separate subscription, and a separate place in the user’s workflow.

The test: Ask: how painfully is this problem felt today? Not how clever the solution is. How painful the problem is. If users are not actively seeking solutions, complaining about existing alternatives, or spending significant time and money working around the problem, there is no market for your AI product. Technical elegance does not create demand. Pain creates demand.

Key takeaway for business professionals

“Can we use AI?” is a technology question. Almost always, the answer is yes. AI can do almost anything.

“Should we use AI?” is a business question.

The answer depends on whether the problem is real, the solution is reliable, the economics work, and the error cost is acceptable.

$5 billion in destroyed capital says that most companies are asking the first question and skipping the second.

The framework does not say never use AI.

It says check seven conditions before you commit. The companies that check will build products that work. The companies that skip will join the graveyard of products that were technically impressive and commercially useless.

Impressive is not a business model. Useful is.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

In 2006, Amazon did something that confused everyone.

It took the computing infrastructure it had built for its own e-commerce business and started renting it to other companies. Servers, storage, databases. Anyone could use them. Pay only for what you consume. No upfront investment. No hardware to manage.

People thought it was a distraction. A side project. A weird move by a bookstore.

That “side project” is now Amazon Web Services. It generates over $100 billion in annual revenue. It is the single largest source of Amazon’s operating profit. It fundamentally changed how every company in the world builds software.

Now Amazon is running the exact same playbook. With logistics.

Recently Amazon launched Amazon Supply Chain Services (ASCS). It is opening its entire logistics network of freight, warehousing, fulfillment, and last-mile delivery to any business, in any industry, regardless of whether they sell on Amazon.

Procter & Gamble has signed up. 3M has signed up. American Eagle Outfitters has signed up. Lands’ End has signed up.

Most people will read this as a product launch. It is not a product launch. It is the most significant strategic move Amazon has made since AWS. And understanding why requires looking at the playbook from first principles.

The playbook. Built for yourself. Then sell it to everyone.

Amazon has a pattern. It is the most consistent strategic pattern in modern business. And most companies still do not see it even after it has worked twice.

Step 1. Build something you need for your own business.

Step 2. Make it so good that it becomes a competitive advantage.

Step 3. Realise that the same capability is painful and expensive for every other company to build.

Step 4. Package it as a service. Sell access to it.

Step 5. Use the revenue from external customers to further improve the capability. Which makes your own business even better. Which attracts more external customers. Flywheel.

AWS followed this pattern exactly. Amazon needed massive computing infrastructure for its e-commerce business. They built it. Then it realised every other company also needed computing infrastructure and most of them were terrible at building it.

So Amazon packaged its infrastructure as a service. Companies paid per use. Amazon reinvested the revenue into better infrastructure. Better infrastructure attracted more customers. More customers funded better infrastructure.

Amazon Supply Chain Services(ASCS) is the same playbook.

Amazon needed a massive logistics network for its e-commerce business. It built it. Thirty years of investment. Cargo planes. Ocean freight. Rail. Trucks. Hundreds of fulfilment centers. Thousands of delivery stations. Route optimization algorithms. Demand forecasting systems. Customs clearance automation. Return processing. Seven-day-a-week delivery.

Now it is packaging all of it as a service. Any business can use Amazon’s logistics network the way any business uses Amazon’s cloud infrastructure. Pay for what you use. No need to build your own.

The question is not whether ASCS will work. The playbook has already been proven. The question is how large it can get and how fast.

What ASCS actually offers

Let us be specific about what Amazon just opened to every business.

Freight. Amazon’s transportation network spans ocean, air, ground, and rail. Any business can now move cargo across this network. Cross-border shipping. Customs clearance. Shipment tracking from origin to destination. Time-sensitive and standard options. This is not a brokerage where Amazon matches you with third-party carriers. This is Amazon’s own fleet. Its own planes. Its own routes. Its own infrastructure.

Procter & Gamble is already using this to move raw materials to production facilities and finished products across its distribution network. 3M is using it to move products from manufacturing sites to distribution centers worldwide. These are not small tests. These are core supply chain operations for two of the largest consumer goods companies on the planet.

Distribution and fulfilment. Amazon’s warehousing network can now store, manage, and ship inventory for any business. Not just for orders placed on Amazon. For orders from any sales channel. Your own website. Shopify. Social media. Physical stores. Wholesale.

This is the capability that changes the economics for mid-size retailers. Building your own warehouse network is a multi-year, multi-million-dollar investment. Staffing it. Managing inventory across locations. Optimizing placement so products are close to demand. Amazon has already solved all of this at a scale no other company can match. Now any business can plug into that solution.

Lands’ End is using this to fulfil orders across multiple sales channels from a single unified inventory pool inside Amazon’s network. One pool of inventory. Multiple destinations. Amazon handles the routing.

Parcel shipping. Amazon’s last-mile delivery network — the part that gets the package from the warehouse to the customer’s door — is now available to any business. Two-to-five-day delivery. Seven days a week. Flexible pickup from your own warehouse or a third-party location. Tracking from label creation to doorstep.

American Eagle Outfitters is using this to deliver online orders from its own website directly to customers nationwide. These packages never touch the Amazon store. They are American Eagle orders, fulfilled through American Eagle’s own e-commerce experience, delivered by Amazon’s logistics network.

This is the detail that matters most. ASCS is not about selling on Amazon. It is about using Amazon’s infrastructure regardless of where you sell.

Why this is harder to replicate than AWS

Here is where the strategic analysis gets interesting.

AWS was revolutionary but conceptually straightforward. Rent computing power instead of buying servers. The shift from physical hardware to cloud was a technology transition. Other companies could (and did) build competing cloud platforms. Google Cloud, Azure, Oracle, IBM. The cloud market has multiple serious players.

Logistics is different. Logistics is physical.

You cannot spin up a warehouse the way you spin up a server. You cannot deploy a fleet of cargo planes the way you deploy a software update. You cannot build a last-mile delivery network covering every zip code in a country by writing code.

Amazon has spent nearly 30 years and tens of billions of dollars building this network. The planes are bought. The warehouses are built. The delivery routes are optimized. The customs clearance systems are automated. The demand forecasting models are trained on decades of data.

Any company that wants to compete with ASCS does not just need money. It needs time. A decade or more of physical infrastructure build-out. And during that decade, Amazon will continue improving its own network, widening the gap.

This is the moat. Not a technology moat. A physics moat. Same concept as Google’s compute commitment to Anthropic. Infrastructure that exists in the physical world is harder to replicate than infrastructure that exists in software.

FedEx and UPS have logistics networks. But they are primarily parcel shipping companies. They do not offer end-to-end supply chain services from overseas factory to customer doorstep. They do not offer warehousing and fulfilment integrated with freight and last-mile. They offer segments. Amazon offers the complete chain.

Shopify has logistics ambitions. But it exited its own fulfilment operations because the capital requirements were too high. It now partners with third-party logistics providers. ASCS is what those third-party providers are now competing against.

The three strategic implications nobody is talking about

Implication 1: Amazon just turned its biggest cost into a revenue line.

Logistics is Amazon’s single largest operating cost. Fulfilment and shipping expenses run into tens of billions annually. Every package Amazon delivers is a cost on its income statement.

ASCS turns that cost centre into a profit centre. Every external business that uses ASCS pays Amazon for the privilege. That revenue offsets Amazon’s own logistics costs. The more external customers use the network, the more the fixed infrastructure costs get distributed across a larger revenue base. The unit economics improve for everyone, including Amazon’s own e-commerce business.

This is the same dynamic that made AWS so profitable. The data centers already existed. Adding more customers to those data centers had a low marginal cost. Revenue grew faster than expenses. Margins expanded.

ASCS will not have AWS-level margins. Logistics involves labor, fuel, and physical goods movement — costs that do not compress the way computing costs do. But the structure is the same. Spread fixed costs across more customers. Generate incremental revenue at attractive margins. Use that revenue to invest further in the network.

Implication 2: Amazon just became the infrastructure layer for its own competitors.

American Eagle sells clothing. So does Amazon. They compete for the same customers. And now American Eagle is using Amazon’s logistics network to deliver orders from its own website.

This is the AWS dynamic repeating. Netflix runs on AWS. Netflix competes with Amazon Prime Video. Amazon profits from Netflix’s success through cloud revenue regardless of which streaming service wins.

ASCS creates the same structure for retail. A clothing brand that competes with Amazon’s private label products can use Amazon’s logistics to deliver its own orders. Amazon profits from the competitor’s success through logistics fees.

This is strategic genius because it creates a situation where Amazon benefits from the growth of the entire e-commerce market, not just its own marketplace. Every retailer that grows online needs logistics. If that retailer uses ASCS, Amazon captures a share of that growth.

The more e-commerce grows, the more logistics capacity is needed. The more logistics capacity is needed, the more businesses turn to ASCS. Amazon becomes the infrastructure layer underneath an expanding market. It does not need to win every product category. It needs to be the logistics provider for the companies that do.

Implication 3: ASCS creates the most powerful data feedback loop in retail.

This is the implication that should make every supply chain professional pay attention.

When a business uses ASCS, Amazon gains visibility into that business’s supply chain. Which products are moving. In what volumes. From which origins. To which destinations. At what frequency. During which seasons.

Amazon already has the most comprehensive demand data in e-commerce through its marketplace. Now it will have supply chain data from businesses that sell outside of Amazon. Combined, this creates a data picture that no other company on earth can match.

Amazon will know what products are selling, where they are selling, how they are being shipped, and what it costs to move them. Across millions of businesses. Across every industry. Across every geography.

This data feeds back into Amazon’s own operations. Better demand forecasting. Better inventory placement. Better route optimization. Better pricing for its own products. Better product selection decisions.

The companies using ASCS get a good logistics service. Amazon gets a logistics service plus the most valuable supply chain dataset in history. The trade is asymmetric by design.

What this means for business professionals

If you work in E-commerce, Operations, logistics or procurement, ASCS changes three things about your job.

The “build vs buy” decision just got harder. Before ASCS, the choice was: build your own logistics capability or use a traditional third-party logistics provider (3PL). Now there is a third option. Use the same logistics network that delivers 7 billion packages a year for the world’s largest e-commerce company. The capability gap between this option and a traditional 3PL is enormous. The cost advantage of Amazon’s scale is significant. Justifying a build-your-own approach just became much harder.

Second, the competitive landscape is shifting. If your competitors adopt ASCS and you do not, they will have access to two-to-five-day delivery across a nationwide network, flexible warehousing that scales with demand, and integrated freight from factory to fulfilment centre. Matching this capability independently requires years and massive capital investment. Not matching it means your customer experience is worse than competitors who plugged into Amazon’s network.

The risk you need to evaluate

The risk with ASCS is the same risk every company faces with AWS. Dependency.

When your logistics runs on Amazon’s network, you are dependent on Amazon’s pricing, Amazon’s reliability, Amazon’s terms, and Amazon’s strategic priorities. If Amazon raises ASCS prices, your costs go up and your alternatives are limited. If Amazon changes its terms of service, you comply or you migrate. Migration from a fully integrated logistics network is not a quarterly project. It is a multi-year operational transformation.

And there is a deeper strategic risk. Amazon competes with many of the businesses that will use ASCS. Amazon has access to data about what products those businesses are shipping, in what volumes, and to which customers. Amazon has a history of observing what sells well on its marketplace and launching competing private-label products.

Will Amazon use ASCS data to inform its own product strategy? Amazon says no. AWS has operated with strict data separation between Amazon’s retail business and AWS customers. The same principle will presumably apply to ASCS. But the incentive structure is worth understanding. And the trust decision is worth making deliberately.

Every business considering ASCS should ask three questions.
→ What is our exit strategy if Amazon’s pricing becomes unacceptable?
→ What data are we sharing and what are the contractual protections?
→ What is the competitive risk of our logistics provider also being our competitor in the product market?

These are not reasons to avoid ASCS. They are reasons to enter with a clear-eyed strategy rather than a convenience-driven decision.

Key Takeaway

Amazon spent 30 years and tens of billions of dollars building the most efficient supply chain on earth. It built it for itself. Now it is selling access to it.

This is the AWS playbook. Build for yourself. Package as a service. Let the flywheel spin.

The companies that used AWS early gained a structural cost advantage over competitors that built their own data centers. The companies that use ASCS early may gain the same advantage over competitors that run their own logistics.

Amazon is not launching a logistics company.

Amazon is becoming the infrastructure layer underneath global commerce.

The way AWS became the infrastructure layer underneath global software.

The playbook worked once. There is no reason to believe it will not work again.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Google is investing up to $40 billion in Anthropic. Anthropic makes Claude. Claude competes directly with Google’s Gemini.

On the surface, this makes no sense. Why would the company that spent billions developing Gemini fund a direct rival? Why would Google help Anthropic build better models that could undercut Gemini in enterprise sales?

Most people read this headline and thought one of two things. Either “Google is hedging its bets” or “Google is buying influence.” Both are partially true. Both miss the deeper game.

This is not a hedge. This is not an acquisition. This is a five-layer strategic play where Google wins in at least four of the five scenarios that could play out over the next five years. And the one scenario where Google does not win? It still does not lose.

Let us break it down from first principles.

The deal structure.

Google is committing $10 billion right now in cash. At a $350 billion valuation for Anthropic. That is the same valuation Anthropic had in its February 2026 funding round.

The remaining $30 billion is contingent on performance milestones. Revenue targets. User adoption metrics. Technical benchmarks.

If Anthropic hits them, Google invests more. If Anthropic misses them, Google keeps its money.

This structure is important. Google is not writing a $40 billion check. It is writing a $10 billion check with a $30 billion option. The option only activates if Anthropic proves it is worth the additional investment.

But the cash is only half the deal.

Google Cloud is also providing 5 gigawatts of computing capacity to Anthropic over the next five years.

Five gigawatts. To put that in perspective, that is enough to power a small city. Or to train and run some of the most powerful AI models ever built.

This compute comes from Google’s TPU infrastructure. Tensor Processing Units. Custom chips that Google designed specifically for AI workloads. These are not Nvidia GPUs. They are Google’s own silicon. And that distinction matters more than most people realize.

Layer 1: The cloud revenue play.

Here is the part most people miss entirely.

When Google invests $10 billion in Anthropic, a significant portion of that money flows right back to Google. Because Anthropic is already one of Google Cloud’s largest customers. And with 5 gigawatts of additional compute capacity committed, Anthropic will spend billions per year on Google Cloud infrastructure.

This is the circular economics of modern AI investment. Google invests in Anthropic. Anthropic spends a large portion of that investment on Google Cloud. Google Cloud books high-margin revenue. Google’s cloud business grows. Google’s stock price benefits.

This is not an invetsment. It is a revenue pipeline disguised as an investment.

Google monetizes Anthropic’s growth immediately through infrastructure spending, regardless of whether Anthropic itself ever becomes profitable. Anthropic bears the risk of reaching profitability. Google captures the revenue either way.

Layer 2: The TPU validation play.

Google has spent years and billions of dollars building its TPU chip architecture. The problem? Convincing the market that TPUs are a legitimate alternative to Nvidia’s dominant GPUs.

Nvidia controls the AI chip market. Every major AI lab has built its training infrastructure on Nvidia hardware. Breaking Nvidia’s dominance requires a credible customer that can demonstrate TPU performance at frontier-model scale.

Anthropic is that customer.

When Anthropic trains Claude, one of the world’s most capable AI models on Google TPUs, it validates the entire TPU platform. It proves that you do not need Nvidia to build frontier AI. It proves that Google’s custom silicon can compete at the highest level.

This is worth more than any marketing campaign Google could run. Anthropic is an independent company, not a Google subsidiary. Its choice to use TPUs is a market signal that carries weight precisely because Anthropic is not obligated to use them. The endorsement is implicit and powerful.

And the economics are compelling. TPUs offer approximately 40% cost reductions compared to Nvidia-dependent alternatives for certain AI workloads. For Anthropic, this means cheaper training and inference. For Google, it means a proof point that attracts other AI companies to Google Cloud.

Every company that sees Anthropic training frontier models on TPUs and thinks “maybe we should consider TPUs too” is a potential Google Cloud customer. The Anthropic deal is not just about Anthropic. It is about every AI company that watches what Anthropic does and follows.

Layer 3: The model hedging play.

Google builds Gemini. Gemini is a strong model. But here is the uncomfortable truth that Google’s leadership understands better than anyone.

Nobody knows which AI model will dominate in three years.

The model landscape changes every six months. A model that leads in January might be third-best by July. The gap between the top models is shrinking. And the competitive dynamics are brutal. Every lab is investing billions in each new generation.

Google’s internal bet is Gemini. But what if Gemini does not win? What if Claude becomes the preferred model for enterprise customers? What if Anthropic’s safety-first approach becomes the regulatory standard that every company must comply with?

If that happens, Google still wins. Because Google owns a significant stake in Anthropic. Google has already held a 14% ownership position before this deal. The new $10 billion investments increases that stake further. If Anthropic’s valuation continues to rise, Google’s stake appreciates accordingly.

This is the hedge. Google wins if Gemini wins. Google wins if Claude wins. Google wins if both win in different market segments. The only scenario where Google does not benefit is if a model from outside both Google and Anthropic dominates the entire market. And even in that scenario, Google still has the cloud revenue from Layer 1.

Layer 4: The enterprise trust play.

This is the subtlest and arguably most important layer.

Enterprise customers do not want to be locked into a single AI model. They want choice. They want the ability to switch between models based on the task, the use case and the evolving capabilities of each model.

Google Cloud’s Vertex AI platform already offers access to multiple models. Gemini for some tasks. Claude for others. Customers pick the best model for the job. Google Cloud hosts both.

The Anthropic investment deepens this positioning. Google Cloud becomes the only platform where enterprises can access both Gemini and Claude with enterprise-grade security, compliance and data controls. A healthcare company can analyze patient records with Claude, knowing the data stays within Google Cloud’s infrastructure. A financial institution can run fraud detection on Gemini while using Claude for regulatory document analysis. All within one platform.

This multi-model strategy is the opposite of vendor lock-in. It is vendor magnetism. Enterprises choose Google Cloud not because they are forced to, but because Google Cloud offers the most models, the most flexibility, and the lowest switching risk.

The enterprise customer does not care which model is “best.” They care about which platform gives them the best access to the best models for their specific needs. Google Cloud’s answer is “both.” That answer is only possible because of the Anthropic investment.

Layer 5: The compute-as-moat play.

There is one resource in AI that money alone cannot solve quickly. Compute.

Training and running frontier AI models requires an extraordinary amount of computing power. The demand for AI compute is growing faster than the supply. Anthropic itself has faced widespread complaints about Claude usage limits in recent weeks. The company literally does not have enough compute to serve all its users.

Google has compute. Massive amounts of it. And with the 5-gigawatt commitment, Google is guaranteeing Anthropic access to computing capacity that Anthropic could not secure on its own at this speed.

This creates a strategic dependency that goes beyond the financial investment. Anthropic needs Google’s compute to grow. Google provides the compute. Anthropic grows. Google benefits from the growth through cloud revenue and equity appreciation.

But here is the deeper play. The compute commitment makes it structurally difficult for Anthropic to fully migrate away from Google Cloud. You cannot casually move 5 gigawatts of compute infrastructure from one cloud provider to another. The physical hardware, the networking, the data pipelines, the training configurations all of it becomes deeply integrated with Google’s infrastructure over time.

This is not lock-in through contracts. It is lock-in through physics. The compute is physically on Google’s servers. The models are optimized for Google’s TPUs. The inference runs through Google’s network. The deeper the integration, the harder the switch.

Five years from now, Anthropic and Google Cloud will be so deeply intertwined at the infrastructure level that separating them would be like separating the engine from the car while driving.

What are some of the risks?

No strategy is perfect. Here are the risks Google is taking.

Risk 1: The competitor-partner tension. Google builds Gemini. Anthropic builds Claude. They are direct competitors in the AI model market. This creates an inherent tension. Will Google Cloud give Claude equal promotional treatment as Gemini? Will Anthropic trust Google with its most sensitive research given that Google could use insights to improve Gemini? Will enterprise customers trust the neutrality of a platform where one of the models is owned by the platform itself?

This tension is manageable today. It could become unmanageable if the competitive dynamics intensify.

Risk 2: Anthropic’s multi-cloud strategy. Anthropic does not exclusively use Google Cloud. Amazon has invested over $8 billion in Anthropic. Anthropic runs on both Google Cloud and AWS. This multi-cloud positioning is strategically intelligent for Anthropic as it avoids dependency on any single provider. But it limits Google’s ability to capture the full economic value of the relationship.

Some portion of Anthropic’s compute spend will always go to Amazon, regardless of Google’s investment.

Risk 3: Anthropic’s IPO wildcard. Anthropic is reportedly considering an IPO as soon as October 2026. An IPO would give Anthropic access to public market capital, reducing its dependency on strategic investors like Google. A public Anthropic might make decisions that prioritize shareholder value over partnership loyalty.

The dynamics of the relationship could shift significantly once Anthropic has independent access to billions in public market funding.

What this means for business professionals.

If you are a consultant, a program manager, or a business leader making AI decisions, this deal has three practical implications for your work.

Implication 1: The multi-model future is now confirmed. If Google itself is investing $40 billion in a competitor’s model, the era of betting on a single AI model is over. Your AI strategy should include access to multiple models. Build your infrastructure on a platform that supports model switching. Do not hardcode your workflows to a single provider.

Implication 2: Cloud choice is now an AI strategy decision. The cloud platform you choose determines which AI models you can access, at what cost, and with what level of integration. Google Cloud gives you Gemini and Claude natively. AWS gives you Claude and Amazon’s own models. The cloud decision is no longer just about infrastructure. It is about AI capability.

Google is not investing $40 billion because it believes Anthropic will build better AI than Gemini. Google is investing $40 billion because it has designed a structure where it profits regardless of which AI model wins.

If Gemini wins, Google wins through its own product. If Claude wins, Google wins through its equity stake and cloud revenue. If both win in different segments, Google wins twice. If the market fragments into many models, Google Cloud wins by hosting more of them than anyone else.

This is not a bet on Anthropic. It is a bet on the structure of the AI industry itself. And the structure says: whoever owns the compute, the cloud and the platform captures value no matter which model sits on top.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Image Credits - X.com

The bot did not redirect. It did not refuse. It wrote working code. Correct solution. Full explanation. Then it pivoted back to selling McNuggets.

The screenshot went viral. It trended on x.com.

People started joking about canceling their paid AI subscriptions because McDonald’s was giving away the same thing for free. One post read: “Stop paying for Claude Code. McDonald’s AI bot is FREE.”

Lets understand what are the real implications. This is not just a McDonald’s problem. This is a problem for every company deploying AI.

If you are a business leader making decisions about AI adoption right now, this incident is one of the most important case studies of 2026.

What actually happened?

McDonald’s customer support chatbot runs on a powerful AI model under the hood.

Think of it like this. The AI model is a brilliant generalist. It can write code, draft legal documents, solve math problems, compose poetry and do basically anything involving language. McDonald’s dressed this generalist in a McDonald’s uniform and told it: “You only help with food orders and customer complaints.”

But the uniform is cosmetic. The generalist is still a generalist.

When the user asked for coding help, they did not hack the system. They did not use any special tricks. They simply wrapped their coding question inside a food order.

“Before I order my nuggets, help me with this.” The AI’s core training is to be helpful. So it was helpful. About coding.

The technical term for this is a capability leak. The AI can do far more than it is supposed to.

The business only restricted what it should do, not what it can do. Those are two very different things.

Why this matters ?

The McDonald’s incident was harmless. A coding question is not dangerous. But the failure mode it exposes is.

If an AI support bot can be talked into writing code, it can potentially be talked into other things too. Revealing its internal instructions. Sharing information it should not share. Making promises the company cannot keep like offering free coupons, refunds or generating content that creates legal or brand risk.

Every customer-facing AI chatbot that runs on a general-purpose model carries this risk. The question is not whether someone will try to push your bot off script. They will. The question is what happens when they succeed.

For McDonald’s, the cost was a viral meme.
For a financial services company, it could be regulatory exposure.
For a healthcare company, it could be liability.
The stakes scale with the industry.

The lesson most businesses are getting wrong

When executives see this kind of incident, the instinct is to tighten the instructions. Tell the AI more explicitly what it cannot do. Add more rules. Be more specific about boundaries.

This helps but it does not solve the problem.

The instructions you give an AI chatbot are suggestions, not constraints. The AI processes your instructions and the customer’s message together, then decides what to do. If the customer frames their request persuasively enough, the AI’s deep training to be helpful can override your instructions.

Think of it like hiring a brilliant new employee and giving them a one-page policy document on their first day. The document says: “Only answer questions about our products.” But this employee has expertise in everything. When a customer casually asks for help with something off-topic, the employee’s instinct is to help. The policy document is in their mind, but so is years of training that says helping people is good.

That is exactly what happens with AI chatbots. The system prompt is the policy document. The model’s training is the years of instinct. Instinct often wins.

What businesses should actually do

The companies getting AI deployment right are not relying on better instructions alone. They are building systems with multiple layers of protection. Here is what that business leaders can do.

Demand a gatekeeper before the AI. Before any customer message reaches the main AI model, it should pass through a simple filter that asks one question: Is this message relevant to our business? If no, the customer gets a polite redirect without the AI ever seeing the message. This is fast, cheap, and eliminates the vast majority of off-topic requests. Ask your engineering team whether this layer exists. If it does not, that is your first priority.

Insist on a tool-based architecture, not free-text responses. This is the single most important technical decision. Instead of letting the AI generate any response it wants, restrict it to a fixed set of actions. Search the menu. Look up a store. Start an order. Escalate to a human. Decline the request. There is no “write code” action. No “answer general knowledge questions” action. The AI picks from your list. Nothing else. This is the difference between telling someone not to open a door and removing the door entirely.

Require output checks before anything reaches the customer. Even with all the above, run every AI response through a final validation step before the customer sees it. Does this response contain anything outside the defined scope? Code? Medical advice? Legal statements? If yes, block it and serve a fallback response. This is your safety net.

Red-team before you launch, and keep red-teaming after. Red-teaming means having people deliberately try to break your AI before customers do. Try to get it off-topic. Try to make it reveal its instructions. Try to make it say things it should not say. Do this before launch. Then do it again every quarter. The attack techniques evolve. Your defenses need to evolve with them.

Treat AI governance like you treat data security. Most companies treat AI deployment as a product decision. Ship the chatbot, measure customer satisfaction, move on. The companies that avoid incidents like McDonald’s treat AI deployment as an ongoing security practice. Continuous monitoring. Anomaly detection. Regular audits. Incident response plans. If you have a CISO for your data, you need an equivalent function for your AI.

The bigger picture

The cost of deploying AI has dropped dramatically. It is now economically viable for any large brand to embed a sophisticated AI chatbot into their customer experience. This is happening across industries. Retail. Financial services. Healthcare. Travel. Telecom. Logistics.

But the speed of deployment is outpacing the maturity of deployment practices. Companies are shipping AI agents with the same level of security consideration they would give to FAQs page. An FAQs page cannot go off-script. An AI agent can.

The McDonald’s incident landed as a meme. The next one might land as a headline. The difference will come down to whether the company treated their AI as a product feature or as an operational risk.

Every business deploying AI right now needs to answer one question honestly: If someone tried to push our AI off-script tomorrow, what would happen?

If you do not know the answer, find out before your customers do.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

“I tried using ChatGPT for that email. It sounded nothing like me. I spent 20 minutes editing it. I could have written it from scratch in 10 minutes.”

This is the number one reason professionals stop using AI for real work. The output sounds generic.
It sounds corporate. It sounds like it was written by a committee of business school textbooks from 2014.

It uses phrases no human has ever said in a real meeting. “Leverage synergies.” “Drive alignment.” “In today’s rapidly evolving landscape.”

You read the output. You cringe. You rewrite the whole thing. And then you tell your colleague that AI is overhyped.

Here is the problem. It is not the model. It is what you did not give the model.

ChatGPT has never read your emails.
It has never seen your Slack messages.
It does not know your writing style, your level of formality, your sentence length, your vocabulary, or the way you structure arguments.
It has no idea that you prefer short sentences.
Or that you never use exclamation marks.
Or that you always open with the conclusion before giving the reasoning.

It knows none of this. So it defaults to the average writing style in its training data.

And the average writing style in its training data is a mix of every blog post, corporate memo, academic paper and marketing brochure published on the internet.

The average of everything is nothing in particular. That is what generic sounds like.

Today we will discuss how to fix two problems at once.
→ How to give the model your voice.
→ How to give the model your context.

Both are solved the same way. By telling the AI what it cannot figure out on its own.

Part 1: Making AI sound like you

How to make AI sound like you

The mirror technique

This is the fastest way to make AI output sound like your writing.

Step 1: Find three examples of your best writing. Emails, Slack messages, documents, presentations. Anything that sounds like you at your best. Copy them.

Step 2: Paste them into ChatGPT with this instruction: “Here are three examples of my writing style. Analyze the tone, sentence structure, vocabulary level, and formatting patterns. Then describe my writing style in 5 bullet points.”

Step 3: Save the description the AI gives you. This is now your style profile.

Step 4: Every time you ask AI to write something for you, include the style profile in your prompt. “Write this in the following style:” followed by those five bullet points.

That is it. The model now has a pattern to match. Instead of defaulting to internet-average writing, it defaults to your writing.

Real example. A program manager did this exercise and got the following style profile from ChatGPT:

“Direct and action-oriented. Opens with the conclusion or decision, then provides reasoning. Short sentences averaging 12–15 words. Avoids qualifiers like ‘I think’ or ‘Perhaps.’ Uses numbered lists for action items. Rarely uses adjectives. Never uses exclamation marks.”

She pasted this style profile into every subsequent prompt. The difference was immediate. The AI’s output went from “I would like to kindly suggest that we consider the possibility of rescheduling” to “We need to move the launch to March 15. Here is why.” That is her voice.

The AI found it because she showed it what to find.

The “write like this, not like that” technique

Sometimes showing examples is not enough. You also need to tell the AI what to avoid. Because the model’s default behaviors include specific patterns that make writing sound robotic.

Add a constraints section to your prompt that explicitly bans the phrases you hate.

“Do not use these phrases: ‘leverage,’ ‘synergise,’ ‘it is important to note,’ ‘in today’s fast-paced world,’ ‘I hope this email finds you well,’ ‘Please do not hesitate to reach out,’ ‘As per our discussion.’ Do not start any paragraph with ‘Furthermore’ or ‘Additionally.’ Do not use passive voice.”

This sounds aggressive. It is the most effective thing you can do. The model defaults to these phrases because RLHF training rewarded safe, professional-sounding language.

These phrases are the safest, most average expressions in business writing. Banning them forces the model to find alternatives. The alternatives are almost always better.

The persona persistence technique

Every new conversation starts from zero. The model forgets everything. Your style profile, your preferences, your context. All gone.

Here is how professionals solve this.

Build a reusable prompt block. A paragraph that contains your style profile, your role, your key constraints and any standing instructions. Save it as a text file or a note on your phone. Paste it at the start of every new conversation.

Here is an example of a reusable prompt block:

“I am a Senior Program Manager at a edtech company. I communicate with VPs and Directors. My writing is direct, concise and action-oriented. I open with decisions and recommendations, then provide reasoning. I use short sentences. I never use filler phrases, passive voice or qualifiers like ‘I think’ or ‘Perhaps.’ I prefer bullet points for action items and numbered lists for priorities. When I ask you to draft something, match this style exactly.”

Paste this once at the start of every conversation. Every output in that conversation will now reflect your voice and preferences. 60 seconds of setup saves 20 minutes of editing on every output.

If you use ChatGPT’s custom instructions feature or Claude’s system prompt, you can set this once and it persists across all conversations automatically. You never have to paste it again.

The editing partnership model

Here is the mental model that changes how you work with AI forever.

Stop treating AI as a writer. Start treating it as a first-draft machine that you edit.

A good human writer produces a first draft and then revises it three or four times. The first draft is never the final product. It is raw material.

AI gives you the first draft in 10 seconds instead of 45 minutes. Your job is revision, not acceptance. Read the output. Cut the filler. Tighten the sentences. Add your judgment. Remove the parts where the AI hedged because it was trained to be cautious. Add the parts only you know because you were in the meeting.

The best professionals using AI today are not people who accept AI output as-is. They are people who get a usable first draft in seconds and then spend 5 minutes turning it into something that has their fingerprint on it.

The AI handles volume. You add your flavour. That is the partnership.

Part 2: Giving AI context that actually works

Now the second problem. Even if the AI matches your style perfectly, the output will still be generic if the model does not know your situation.

“Write me a Project status update” is a style-matched prompt with zero context. The AI will produce a beautifully written status update about a fictional project for a fictional team with fictional metrics. It will describe nothing real.

Context is the difference between AI that sounds like you and AI that knows what you are talking about.

What context actually means

Context is any information that only you have and the model does not.

Your company’s name, products and strategy. Your team’s current projects and timelines. The names and roles of your stakeholders. The metrics you track. The decisions that have been made. The risks on the table. The politics in the room. Your industry’s specific terminology. Your customer’s specific pain points.

None of this exists in the model’s training data. Or if it does, it is outdated and incomplete. The model’s knowledge of your company is whatever was publicly available before its training cutoff. Your internal roadmap, your last sprint review, your VP’s concerns about the Q3 timeline. None of that exists for the model.

Until you provide it.

The three levels of context

Level 1: Inline context. You paste the relevant information directly into the prompt.

“Here is our Q2 roadmap: [paste the roadmap]. Here are the three blockers from last week’s sprint review: [paste the blockers]. Write a status update for the VP of Engineering covering progress against the roadmap and the impact of these blockers on the Q3 timeline.”

This is the simplest and most common approach. Paste the relevant data. Ask the model to work with it. The output is instantly more specific because the model has real information to work with instead of inventing generic placeholders.

Level 2: Document context. You upload a file or paste a large document and ask the model to use it as a reference.

“I am uploading our 30-page product strategy document. Read it carefully. Now write a 5-minute presentation script summarizing the three strategic bets for a non-technical board audience.”

The model reads the document. It extracts the key points. It structures the presentation. The output is grounded in your actual strategy, not in generic strategy frameworks from Harvard Business Review.

This works with meeting transcripts, research reports, competitive analyses, customer feedback compilations, and any other document your team produces. The model becomes dramatically more useful the moment it has access to your real documents.

Level 3: Persistent context. You set up context that the model remembers across conversations.

ChatGPT’s memory feature and custom instructions allow you to store persistent context. “I work at a Fintech company. Our product is a B2B payments platform. My team of 8 engineers is building a real-time fraud detection module. Our VP of Product is Sarah. Our main competitor is Stripe.”

Once stored, this context applies to every conversation. You do not need to re-explain your company, your team or your project every time you start a new chat. The model already knows.

Claude’s Projects feature does something similar. You can upload multiple documents into a Project and every conversation within that Project has access to all the documents. Your entire product strategy, your team wiki, your OKRs, your last three board decks. All available to the model in every conversation.

This is where AI stops being a generic tool and starts being a personalized work partner.

The context quality test

Not all context is equally useful. Here is how to test whether the context you are providing will actually improve the output.

The “could this apply to any company?” test. Read your prompt. If someone at a completely different company could send the same prompt and get a useful response, your prompt lacks context. “Write a stakeholder update” passes the test for any company. It needs context. “Write a stakeholder update for the payments migration project covering the API integration delay and its impact on the Stripe partnership timeline” fails the test. It is specific to your situation. That means the context is doing its job.

The “would I tell this to a new team member?” test. Imagine a smart new intern joining your team today. What would you tell them before asking them to write this document? Their role. The project background. Who is reading it. What has happened recently. What matters. What does not. Tell the AI the same things you would tell that new hire.

The “can the model invent this?” test. If the information is publicly available, widely known, or general knowledge, the model probably does not need you to provide it. If the information is internal, recent, specific to your team, or based on conversations that happened in a room, the model absolutely needs you to provide it.

The context injection framework

Here is the practical framework for adding context to any prompt.

1. WHO is reading this?
[Name, role, what they care about]

2. WHAT has happened?
[Recent events, decisions, data, context]

3. WHERE does this fit?
[Project, workstream, initiative, timeline]

4. WHY does this matter?
[Stakes, urgency, implications]

5. WHAT should the model NOT assume?
[Misconceptions to avoid, context the model
might guess wrong about]

Fill in each field. Paste it before your main instruction. The model now has a briefing packet before it starts generating. The output will reflect your actual situation instead of a generic one.

Real example. Without context injection:

“Write an email to the Engineering Lead about the timeline.”

With context injection:

“WHO: Rahul, Engineering Lead. Reports to the CTO. Cares about scope clarity and team capacity. WHAT: The design team delivered final specs 2 weeks late. This pushes the development start from April 1 to April 15. WHERE: Project Atlas, our new customer onboarding flow. Target launch is June 30. This is the CEO’s top priority. WHY: If development starts April 15, we either cut scope or miss the June 30 deadline. Both options need Rahul’s input. DO NOT ASSUME: Do not assume Rahul knows about the design delay. This email is the first time he is hearing this.

Write a direct, respectful email to Rahul explaining the situation and asking for a 30-minutes meeting to discuss options.”

The first prompt produces a vague, generic email about “timeline concerns.” The second produces an email that reads like it was written by someone who is actually on the project because the model had the context that only someone on the project would have.

DIY for Business Professionals:

Here is the combined workflow that makes AI output feel like it came from you, about your actual work, in your actual voice.

Step 1. Build your style profile. Run the mirror technique once. Save the five bullet points.

Step 2. Build your context block. Company, team, role, key stakeholders, current priorities. Save it.

Step 3. For every important AI task, paste both blocks, fill in the context injection framework, and then give your specific instruction.

The total setup takes 90 seconds. The output saves 30 minutes. And the output actually sounds like something you would send.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Professional A types a prompt: “Write a strategy update.”

Professional B types a prompt: “Write a 300-word strategy update for our VP of Product summarizing Q1 progress on the personalization roadmap. Include three wins, one risk, and a specific ask for Q2 headcount. Tone should be confident but realistic. Use bullet points for the wins.”

Both hit enter. Both get a response in under 10 seconds.

Professional A gets a generic, fluffy, three-paragraph essay that could apply to any company in any industry. It sounds like a template from a business writing textbook. It is technically correct and practically useless.

Professional B gets a tight, specific, structured update that reads like it was written by someone who knows the project. It has the right tone for a VP audience. It has the right level of detail. It needs light editing, not a rewrite.

Same model. Same technology. Same subscription fee. The difference is the prompt. And the difference in output quality is not 10% or 20%. It is the difference between starting over and shipping.

This is the most important skill. Not because prompting is complicated. Because it is misunderstood.

What most people think a prompt is

Most professionals think of a prompt as a question.

You ask the AI something. It answers.

Like typing into Google. Like asking a colleague.

This mental model is wrong. And it is the single biggest reason most professionals get mediocre results from AI.

A prompt is not a question.

A prompt is an input that determines an output.

The quality, specificity and structure of the input directly determines the quality, specificity and structure of the output.

There is no intelligence sitting on the other side “understanding” your intent and filling in the gaps.

There is a prediction engine that generates output based on the patterns activated by your exact words.

When you type “Write a strategy update,” here is what happens inside the model.

The tokens get converted to embeddings. The embeddings activate patterns in the model’s learned representations. “Write” activates general writing patterns. “Strategy” narrows it slightly. “Update” narrows it a bit more. But the intersection of “write” + “strategy” + “update” is still enormous.

Millions of documents in the training data match that pattern.

→ Consulting decks
→ Blog posts
→ Textbook examples
→ MBA assignments
→ Corporate memos

The model picks from all of them. The result is an average of everything. Generic by definition.

Now look at Professional B’s prompt.
→ “300-word” constrains the length
→ “VP of Product” constrains the audience and tone
→ “Q1 progress on the personalisation roadmap” constrains the content domain
→ “Three wins, one risk, and a specific ask for Q2 headcount” constrains the structure.
→ “Confident but realistic” constrains the tone.
→ “Bullet points for the wins” constrains the format.

Each constraint eliminates millions of possible outputs. What remains is a narrow band of responses that match all the criteria simultaneously. The model is not smarter when given a better prompt. It has fewer wrong directions to wander.

This is the mental model. A prompt is not a question you ask. It is a set of constraints you impose.

The coordinate system mental model

Here is the framework that changes everything.

Think of the AI model as an enormous map. This map contains every possible text output the model could generate. Every email, every report, every poem, every code snippet, every strategy memo. All possible outputs exist somewhere on this map.

Your prompt is a set of coordinates. It tells the model where on the map to go.

A vague prompt gives vague coordinates. “Somewhere in the northern hemisphere.” The model lands somewhere in the general vicinity. Maybe Paris. Maybe Moscow. Maybe Reykjavik. All are technically correct. None are specifically useful.

A specific prompt gives precise coordinates. “48.8566 north, 2.3522 east.” The model lands exactly at the Eiffel Tower. No ambiguity. No wandering. No luck involved.

The output you get is not random. It is the direct consequence of how precisely your coordinates pointed.

This is why the same model produces brilliant output for one person and garbage for another. The model did not change. The coordinates did.

The five dimensions of a prompt

Every prompt, whether you realize it or not, operates across five dimensions. When you leave a dimension unspecified, the model fills it with its default. The defaults are always generic. Specifying each dimension narrows the output from “anything is possible” to “this is exactly what I need.”

Dimension 1: Role

Who is the AI in this conversation?

Unspecified: The model defaults to “generic helpful assistant.” The output sounds like a customer service bot trained to be pleasant and inoffensive.

Specified: “You are a senior McKinsey consultant specialising in digital transformation for retail companies.” Now the model activates patterns from consulting language, strategic frameworks, retail industry terminology and executive communication styles.

This works because the model has seen millions of documents written by consultants, doctors, engineers, lawyers and marketers. When you assign a role, you tell the model which subset of its training data to draw from.

The role is a filter, not a costume.

Real example. If you ask ChatGPT “How should I approach this negotiation?” and you will end up getting generic advice. Now if you ask “You are a Harvard-trained negotiation expert who has coached Fortune 500 CEOs. How should I approach this negotiation with a vendor who is our only supplier for a critical component?” and you will get advice that references anchoring, leverage dynamics and relationship preservation. Same model. Different role. Different output entirely.

Dimension 2: Task

What specifically does the AI need to produce?

Unspecified: “Help me with this report.” The model does not know if you want a draft, an outline, feedback on an existing report, a rewrite, a summary or a critique. It guesses. The guess is usually wrong.

Specified: “Rewrite the executive summary of this report in 200 words, focused on the three key findings, written for a non-technical board audience.” Now the model knows the task (rewrite), the scope (executive summary only), the constraint (200 words), the focus (three findings) and the audience (non-technical board).

The more precisely you define the task, the less the model has to guess.

Every guess the model makes is a potential point of divergence from what you actually want.

Dimension 3: Context

What background information does the AI need to produce a relevant output?

This is the dimension most professionals neglect entirely. They ask the AI to produce something without giving it any context about their situation.

“Write a cold outreach email” gives the model nothing to work with. Write a cold outreach email about what? To whom? From what kind of company? Offering what value? At what stage of the sales cycle?

“Write a cold outreach email from a B2B SaaS startup that sells inventory management software to mid-market retail companies. The recipient is a VP of Operations at a 500-store retail chain. Our software reduced inventory carrying costs by 23% for a similar retailer last quarter. This is the first touch.” Now the model has the sender, the recipient, the product, the value proof, and the stage. Every piece of context eliminates thousands of generic alternatives.

Context is the most powerful dimension because it is the one the model cannot infer. The model can guess at a reasonable tone. It can guess at a reasonable structure. It cannot guess that your company sells inventory management software to mid-market retailers. That information only exists in your head until you put it in the prompt.

Dimension 4: Format

What should the output look like?

Unspecified: The model defaults to prose paragraphs. Sometimes that is what you want. Often it is not.

Specified: “Present this as a table with four columns: Feature, Current State, Target State and Owner.” Or “Give me five bullet points, each one sentence.” Or “Structure this as a SCQA (Situation, Complication, Question, Answer) framework.” Or “Write this as a Slack message, not an email.”

Format specification is the fastest way to improve output quality because it requires zero additional thinking on your part. You already know what format you want. You just forget to tell the model.

Real example. “Compare these three project management tools” without format specification produces a rambling essay. “Compare these three project management tools in a table with rows for pricing, key features, integrations, use cases and limitations” produces a clean, scannable, immediately useful comparison.

Dimension 5: Constraints

What should the AI avoid or limit?

This is the dimension that turns good output into great output. Constraints are boundaries. They tell the model what not to do.

“Do not use jargon.” “Keep it under 150 words.” “Do not include disclaimers.” “Do not start with ‘In today’s fast-paced world.’” “Avoid bullet points.” “Do not suggest options I have not asked for.” “Use only information from the document I provided.”

Constraints are powerful because the model’s default behaviour includes a lot of filler, hedging and generic phrasing that RLHF trained it to produce. Human evaluators rewarded safe, comprehensive responses. So the model defaults to being thorough and cautious. Constraints override these defaults.

“Write a product description” produces 200 words of marketing fluff. “Write a product description. Maximum 50 words. No adjectives like ‘innovative’ or ‘cutting-edge.’ Focus only on what the product does, not how it feels.” produces a tight, honest, useful description.

The constraint is where the professional voice enters the prompt.

The prompt quality equation

Here is the formula.

Output Quality = f(Role, Task, Context, Format, Constraints)

Leave one dimension at zero and the model fills it with generic defaults. Leave two dimensions at zero and the output becomes noticeably worse. Leave three or more at zero and you get the kind of response that makes people say “AI is not that useful.”

AI is exactly as useful as your prompt is specific.

The model generates output based on the patterns activated by your input. More specific input activates more specific patterns. More specific patterns produce more specific output.

The input-output mental model in practice

Here is the shift in thinking that separates casual AI users from professionals who get real work done with AI.

Casual user thinking: “I will ask the AI and see what I get.”

Professional thinking: “I know what output I need. Let me reverse-engineer the input that produces it.”

The professional starts with the desired output and works backward. What should the final document look like? Who is reading it? How long should it be? What sections should it have? What tone is appropriate? What should it definitely not include?

Every answer to these questions becomes a component of the prompt. By the time the professional types the prompt, they have already designed the output. The AI is the execution engine. The professional is the architect.

This is the input-output mental model. The output is a function of the input. Control the input and you control the output. Not perfectly. The model still has randomness from temperature and the prediction process. But the variance shrinks dramatically when the input is precise.

Real example of reverse-engineering a prompt.

Desired output: A one-page brief for the CEO summarising why we should invest in an AI-powered customer support chatbot.

Now let’s work backward:

→ Who reads this? CEO. So the tone is executive-level. No technical jargon. Focus on business impact.
→ How long? One page. So roughly 400 words.
→ What structure? Problem, solution, expected ROI, risk, recommendation.
→ What does the CEO care about? Revenue impact, cost savings, customer satisfaction, timeline.
→ What should it avoid? Technical architecture details. Implementation specifics. Vendor comparisons.

Now write the prompt:

“You are a senior product manager presenting to the CEO. Write a 400-word executive brief recommending investment in an AI-powered customer support chatbot. Structure: problem statement (current support costs and wait times), proposed solution (AI chatbot handling tier-1 queries), expected ROI (cost reduction and CSAT improvement), key risk (hallucination in customer-facing responses), and a clear recommendation with timeline. Tone: confident, data-driven, no technical jargon. Do not include vendor names, architecture diagrams, or implementation details.”

That prompt specifies all five dimensions. Role (senior PM to CEO). Task (400-word executive brief). Context (customer support chatbot investment). Format (five-section structure). Constraints (no jargon, no vendors, no architecture).

The output from this prompt will be dramatically better than “Write a brief about an AI chatbot.” Not 10% better. Unrecognisably better.

Key takeaways for Business Professionals

Your prompt is not a question. It is a set of coordinates on a map of all possible outputs.

Vague coordinates land you somewhere generic. Precise coordinates land you exactly where you need to be.

Five dimensions define those coordinates. Role. Task. Context. Format. Constraints. Specify all five and the model has almost no room to wander. Leave them unspecified and the model defaults to average.

The professionals who get extraordinary results from AI are not using a different model. They are not using a secret tool. They are giving better coordinates.

Start with the output you want. Work backward to the input that produces it. That is the entire game.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

None of the cases existed.

ChatGPT had generated six fictional court cases with the confidence and structure of real ones. The lawyer submitted the brief to a federal court without checking. The judge checked. The lawyer was sanctioned. The story became international news.

Most professionals read that story and think “that lawyer was careless.” That is the wrong lesson.

The right lesson is this. ChatGPT did exactly what it was designed to do. The lawyer just did not understand what that was.

AI hallucination is not a malfunction. It is not a bug that will be fixed in the next update.

It is a direct and unavoidable consequence of how language models work. And until you understand why it happens, you cannot protect yourself from it.

Today we will go to the root cause. Then we will build the framework that ensures you never get caught the way that lawyer did.

Why hallucination happens. The first-principles explanation.

Go back to Day 3. ChatGPT predicts the next token. One word at a time. It calculates probabilities for every possible next word and picks one. Then repeats.

Here is the critical detail most people miss.

At no point in this process does the model ask “Is this true?”

→ There is no fact-checking step. There is no verification layer.
→ There is no database of truth that the model consults before generating a word.
→ The model does not know the difference between a true statement and a false statement. It only knows the difference between a probable statement and an improbable statement.

“The capital of France is Paris” is a highly probable sequence of words. The model has seen this pattern thousands of times in its training data. So it generates it confidently. And it happens to be true.

“The Supreme Court case Hernandez v. Delta Airlines (2019) established the precedent for…” is also a highly probable sequence of words. The model has seen thousands of legal citations that follow this exact structure.

Case name. Versus. Organization. Year. Legal outcome.

The pattern is strong. So the model generates it confidently. But this time, the case does not exist. The model generated the pattern without the fact.

This is hallucination. The model is not lying.

Lying requires knowing the truth and choosing to say something different.

The model does not know the truth. It knows patterns. And sometimes patterns produce sequences that look real but are not.

The sentence structure is correct. The formatting is correct. The language is correct. Everything about the output follows the pattern of a real citation. Except the actual content is fabricated.

The five types of hallucination you will encounter at work

Not all hallucinations are the same. Understanding the types helps you catch them before they cause damage.

Type 1: Fabricated facts

The most common and the most dangerous. The model generates specific details that do not exist.

“According to a 2024 McKinsey report, 73% of enterprises have adopted AI in at least one business function.”

This sounds like a real statistic. McKinsey does publish such reports. The percentage sounds plausible. The framing is exactly how a consulting report would be cited. But the specific number might be completely fabricated.
→ The report might not exist.
→ Or the report exists but says 65%, not 73%. Or the report says 73% but it was published in 2023, not 2024.

The model is not pulling from a McKinsey database. It is predicting what a McKinsey citation should look like based on patterns it learned from thousands of similar citations in its training data.

Where you will encounter this: Research summaries, market analysis, any output that cites specific numbers, dates or sources.

Type 2: Confident nonsense

The model generates an answer that sounds authoritative but is completely wrong.

Ask ChatGPT “What is the population of some small town in India?” It will give you a number. That number might be close. It might be wildly off. It might be the population from 2001. It might be the population of a different town entirely. But the model will state it with the same confidence it uses to tell you the capital of France.

The model has no internal confidence meter. It does not say “I am 95% sure about Paris but only 40% sure about the small town.” Every output gets the same confident tone because confident language patterns are what RLHF trained it to produce. Human evaluators ranked confident, clear responses higher than hedging, uncertain ones. So the model learned to always sound sure. Even when the underlying prediction is weak.

Where you will encounter this: Niche topics, specific local information, anything outside the model’s heavy training data, technical questions about narrow domains.

Type 3: Outdated information presented as current

The model’s training data has a cutoff date. GPT-4o’s training data goes up to a specific point. Anything that changed after that point, the model does not know about. But it will not tell you that.

Ask “Who is the CEO of Google?” and the model will give you an answer based on its training data. If the CEO changed after the cutoff, the model confidently gives you the old name. It does not say “I am not sure because my data might be outdated.” It states the old name as if it is a current fact.

Where you will encounter this: Current events, leadership positions, stock prices, regulations, anything that changes over time.

Type 4: Blended information

The model merges details from multiple real things into one fictional thing.

Ask about a specific research paper on AI in supply chain management. The model might generate a response that combines the title from one real paper, the author from a different real paper, and the findings from a third real paper. Each piece is real. The combination is fiction. The paper as described does not exist. But every component came from a real source, making it incredibly difficult to spot.

Where you will encounter this: Academic references, product comparisons, historical events with multiple similar incidents.

Type 5: Logical hallucination

The model generates a chain of reasoning that sounds logical but contains a hidden flaw.

“The company grew revenue by 10% each year for 5 years. Total growth over the period was 50%.”

10% per year for 5 years is not 50%. It is 61%. Because each year’s 10% is calculated on a larger base than the previous year. Year 1 adds 10. Year 2 adds 11. Year 3 adds 12.1. The model has seen thousands of paragraphs that multiply rate by time to get total. The shortcut sounds reasonable. The math does not work that way.

Where you will encounter this: Financial analysis, strategic reasoning, any output that chains multiple steps of logic together.

Why hallucination cannot be fully eliminated

Here is the uncomfortable truth that most AI companies will not say directly.

Hallucination is not a problem to be solved. It is a trade-off to be managed.

The same mechanism that allows ChatGPT to write creative poetry, generate novel business strategies and produce original marketing copy is the same mechanism that produces hallucinations. Both require the model to generate sequences it has never seen before.

Creativity and hallucination are two sides of the same coin.

If you eliminated hallucination entirely, you would also eliminate creativity. The model would only produce sequences that exactly match its training data.

It would become a search engine, not a generative tool. It could retrieve but not create.

This is why every model update reduces hallucination but never eliminates it. The companies are tightening the boundary between creative generation and factual accuracy. But the boundary can never be perfectly drawn because the model itself does not know the difference.

Newer techniques help but none of these eliminate the fundamental issue:

→ RAG reduces hallucination by giving the model real documents to reference.
→ Fine-tuning on domain-specific data reduces hallucination within that domain.
→ Guardrails can catch some hallucinated outputs before they reach the user.

The model predicts probable sequences. Sometimes probable is not true.

This is why the burden of verification falls on you. Not on the model. Not on the AI company but on the professional using the output.

The 5-step verification framework

Here is the framework that ensures you never submit fabricated court cases, share invented statistics, or base a business decision on hallucinated data.

Step 1: Classify the stakes

Before you verify anything, ask yourself one question. What happens if this output is wrong?

Low stakes. An internal brainstorming document. A first draft of a creative brief. An outline for a presentation you will rewrite anyway. If the AI hallucinates here, the cost is minutes of your time.

Medium stakes. A client-facing report. A market analysis. A project plan shared with stakeholders. If the AI hallucinates here, the cost is your credibility.

High stakes. A legal document. A financial filing. A medical recommendation. A published article with your name on it. If the AI hallucinates here, the cost is your career, your company, or someone’s wellbeing.

The level of verification should match the stakes. Low stakes get a quick scan. High stakes get full verification of every factual claim.

Most professionals apply the same level of trust to all AI output. This is the mistake. You do not need to fact-check a brainstorming session. You absolutely need to fact-check a board presentation.

Step 2: Flag the verifiable claims

Go through the AI’s output and identify every claim that is verifiable. Statistics. Dates. Names. Quotes. Citations. Historical events. Product features. Company information. Legal references.

These are the hallucination risk zones. General observations and logical arguments are lower risk. Specific factual claims are higher risk. Every specific claim needs a source that is not the AI itself.

A useful rule: if the output includes a number, name or date flag it.
These are the three categories where hallucination is most frequent and most dangerous.

Step 3: Verify against primary sources

For every flagged claim, check the primary source. Not another AI. Not a summary site but the actual source.

The model says “According to Gartner’s 2025 report, 65% of enterprises have deployed GenAI.” Go to Gartner’s website. Find the actual report. Check the actual number.

→ If the report does not exist, the claim is hallucinated.
→ If the report exists but says a different number, the claim is distorted.
→ If the report exists and confirms the number, you are good.

This takes time. That is the trade-off. AI saves hours of drafting. Verification costs minutes of checking. The net is still massively positive. But the checking step is not optional.

Step 4: Cross-reference with a second model

This is a technique most professionals do not use and should.

Take the factual claims from ChatGPT’s output and paste them into Claude or Gemini or Perplexity. Ask the second model to verify each claim.

→ If both models produce the same specific fact, the probability of accuracy is higher.
→ If they contradict each other, one of them is hallucinating.
→ If both hedge or say they are unsure, the fact probably needs manual verification.

This is not foolproof. Both models can hallucinate the same wrong fact if it appears in both their training datasets. But disagreement between models is a reliable signal that something needs checking.

Step 5: Add the uncertainty layer

When you use AI-generated content in professional work, add appropriate hedging to any claim you could not fully verify.

Instead of “73% of enterprises have adopted AI” write “Industry estimates suggest approximately 70–75% of enterprises have adopted AI in some form.”

The hedging signals to your audience that the number is directional, not precise. If the number turns out to be wrong, the hedging protects your credibility.

Better yet, only include claims you have personally verified against primary sources. If you could not find the source, cut the claim. A shorter, accurate document is always better than a longer, hallucinated one.

Prompting techniques that reduce hallucination

Beyond the verification framework, there are things you can do before the AI generates its output to reduce the likelihood of hallucination.

Tell the model to only use information you provide. If you paste a document and ask for a summary, add “Use only information from the provided document. Do not add any external facts or statistics” in your prompt. This constrains the model to the text you gave it, reducing the chance it will invent additional details.

Ask the model to flag uncertainty. Add “If you are not confident about any fact, explicitly say so” in your prompt. This does not guarantee honesty. The model still does not truly know what it is confident about. But it activates patterns from its training where uncertainty was expressed, which sometimes produces more hedged and accurate outputs.

Request sources for every claim. Add “Cite the source for every factual claim.” If the model cannot provide a real, verifiable source, the claim is likely hallucinated. Real sources can be checked. Made-up sources are immediately obvious once you try to verify them.

Break complex tasks into steps. Instead of “Write a complete market analysis of the EV industry in India with statistics and competitor data,” break it into parts. “List the top 5 EV companies in India by market share.” Verify. Then “What was the total EV sales volume in India in 2025?” Verify. Then assemble. Each smaller claim is easier to check than a monolithic document full of embedded statistics.

Use AI for structure, not for facts. The safest way to use AI is to let it handle the parts where hallucination does not matter like structure, phrasing, formatting, flow and supply the facts yourself. Paste your verified data. Ask the model to organise it into a report. The model arranges your facts. It does not invent new ones.

Key takeaways for Business Professionals

AI does not hallucinate because it is broken. It hallucinates because it was built to predict probable sequences, not true sequences.

Probable and true overlap most of the time. That is why AI output is usually accurate. But they diverge often enough that unchecked AI output will eventually burn you.

The fix is not better AI. The fix is a verification habit.
→ Classify the stakes
→ Flag the claims
→ Check the sources
→ Cross-reference with a second model
→ Hedge what you cannot confirm

Follow these five steps to avoid any career-damaging mistake.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

That is not right.

Nvidia wins because it built a software prison that everyone is now locked in. The prison is called CUDA.

In this article, I will break down how a chip company became a software monopoly. Why competitors with better specs still lose. And what this means for every non-technical professional trying to understand the AI landscape in 2026.

The Question Nobody Asks

Nvidia holds somewhere between 80% and 86% of the AI accelerator market. Its market cap makes it one of the most valuable companies on the planet.

The standard explanation is simple. Nvidia makes the fastest GPUs. The H100, the Blackwell B200, the upcoming Rubin R100. Each generation is faster than the previous one.

But here is the problem with that explanation.

AMD makes competitive chips and it is cheaper. On paper, it should win workloads. Google has TPUs. Amazon has Trainium. Every major tech company is building custom silicon.

Yet Nvidia keeps winning. Quarter after quarter.

If it were just about hardware, this should not be possible. Better chips at lower prices should take market share. That is how markets work.

Unless something else is going on.

What CUDA Actually Is

CUDA stands for Compute Unified Device Architecture. Nvidia released it in 2007. On the surface, it is a programming platform that lets developers write code for GPUs.

CUDA is an entire ecosystem. It includes programming languages, compilers, math libraries, debugging tools, optimization frameworks and pre-built solutions for specific workloads like deep learning, linear algebra, and signal processing.

Nearly 6 million developers use CUDA and Nvidia software tools. Every major AI framework, PyTorch, TensorFlow is optimized for CUDA first. Often CUDA only.

When a researcher writes a new machine learning algorithm, they write it in CUDA. When a company trains a large language model, the training code runs on CUDA. When a startup builds an AI product, the inference pipeline is built on CUDA.

This is not a feature advantage. This is an ecosystem lock-in.

The Trap Mechanism: How Software Eats Hardware

Let us trace how the trap actually works. There are three layers to it.

Layer 1: Developer Muscle Memory

Every machine learning course teaches CUDA. Every GPU programming tutorial uses CUDA. PhD students learn CUDA before they learn anything else about GPU computing. By the time a developer joins a company, CUDA is the only framework they know deeply.

This is the Adobe effect. Design Colleges teach Photoshop. Students learn Photoshop. Companies hire people who know Photoshop. Nobody switches to other software even though it is free. The switching cost is not the software license. It is the retraining of every person in the pipeline.

Nvidia understood this two decades ago. It invested billions in making CUDA the default in universities and research labs. That investment now compounds every single year.

Layer 2: The Library Moat

CUDA is not just a language. It comes with different libraries for different functions.

Each of these libraries represents thousands of engineering hours of optimisation. They are tuned for Nvidia hardware down to the individual instruction level.

When AMD or Intel releases a competing chip, the hardware might be competitive. But the software libraries are years behind. A researcher running a training job does not care about theoretical time. They care about actual time to completion. And actual time to completion depends on how well the software stack is optimised.

This is why benchmarks are misleading. A chip that is 20% faster on paper can be 30% slower in practice if its software stack is immature.

Layer 3: The Compounding Network Effect

More developers use CUDA. So more libraries get built for CUDA. So more frameworks optimise for CUDA. So more companies deploy on CUDA. So more developers learn CUDA.

Cuda Platform Flywheel

This is a classic platform flywheel. But it has been spinning for almost 20 years. That is a long time for a flywheel to build momentum.

Every new AI breakthrough like GPT happened on CUDA. Each breakthrough pulled more developers into the ecosystem. Each developer made the ecosystem stickier.

Why Competitors Cannot Catch Up

The issue is not whether alternative software exists. It does. The issue is whether the entire chain of dependencies, from the researcher writing a prototype to the production engineer deploying a model, works as seamlessly on the alternative as it does on CUDA.

Today the answer is no. Not even close.

Here is a concrete example. A machine learning researcher writes a new attention mechanism. They test it on their local Nvidia GPU using PyTorch. The code uses CUDA kernels under the hood. The researcher does not think about this. It just works.

Now ask that researcher to port their code to AMD’s software. Some operations will not have optimised kernels. Some will behave slightly differently. The debugging tools are less mature. The community support is thinner. What took a day of work now takes a week.

Multiply this by every researcher at every AI lab and every company in the world. That is the switching cost.

It is not that switching is impossible. It is that switching is painful enough that most people do not bother. And as long as most people do not bother, the ecosystem gap keeps widening.

The $26 Billion Bet

Nvidia is not resting on its moat. It is actively deepening it.

The company recently invested $26 billion into its software ecosystem. That is not a typo.

Twenty-six billion dollars. On software. From a “chip company.”

Jensen Huang’s strategy is clear. Make the software layer so deep, so optimized and so integrated that switching to competitor hardware becomes economically irrational. Even if the competitor’s chip is better.

→ This is the same playbook Microsoft ran with Windows and Office.
→ The same playbook Apple runs with iOS and its app ecosystem.

The same playbook that every successful platform company has run since the dawn of computing.

Own the software. Make the hardware replaceable. Then make sure your hardware is the only thing the software runs on perfectly.

The Cracks in the Wall

No moat is permanent. And the CUDA moat has some real vulnerabilities.

Google’s TPUs, Amazon’s Trainium, and Microsoft’s Maia chips do not need CUDA. These companies build their own software stacks from scratch, optimised for their own hardware. As hyperscalers handle more AI workloads internally, CUDA’s relevance at the top of the market could decline.

But here is the catch. Hyperscaler chips are optimised for specific internal workloads. They do not compete with Nvidia for the general-purpose AI market.

A startup building a new AI product is not going to design a custom chip. They are going to buy Nvidia GPUs.

What This Means For You

If you are a business professional trying to understand AI strategy, the CUDA trap is one of the most important dynamics in the industry.

Any company claiming to compete with Nvidia on hardware alone is fighting the wrong war. The winners will be those who crack the software ecosystem problem.

Final Takeaway

What you have is a company that figured out, two decades ago, that the real power in computing is not in the chip. It is in the tools people use to program the chip.

Nvidia did not invent the best GPU and then build software for it. It built the best software and then made sure the software only worked perfectly on its GPUs.

This is the CUDA Trap.

The chip is the commodity. The software is the moat.

And the most expensive lock-in is the one you never notice.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.

Word by word. Token by token.

But here is the question Day 3 did not answer.

How did ChatGPT get good at predicting words in the first place?

You know it predicts the next token. But why are those predictions so accurate?

Why does it produce coherent paragraphs instead of random word salad?

Why does it understand that “Write me a professional email” should produce a formal greeting and not a recipe for pasta?

The answer is not in the architecture. It is in the training.

And the training process is where most explanations go wrong. They either make it sound too magical or too mathematical. It is neither.

It is a three-stage pipeline.

Each stage does something specific. Each stage solves a specific problem. And understanding these three stages explains why every AI tool you use behaves the way it does.

Stage 1: Pre-training. Read the internet.

This is where an LLM is born.

Before GPT-4o could write you a single email, it had to learn language from scratch. It had no grammar lessons. No dictionary. No teacher explaining what words mean. It had one thing. Text. An incomprehensible amount of text.

Books, Wikipedia, News articles, Scientific papers, Reddit discussions, GitHub code, Forum posts, Product reviews, Legal documents, Medical journals, Recipes, Song lyrics, Corporate filings, Blog posts…

The collective written output of humanity, scraped from the internet and fed into a system.

How much text? For modern frontier models, the training data runs into trillions of tokens. Not billions but Trillions.

If you sat down and read one word per second, 24 hours a day, it would take you roughly 31,000 years to read what GPT-4 was trained on.

Now here is the part that surprises most people.

The training objective is absurdly simple.

The model is shown a sequence of words with the last word hidden. It has to predict what the hidden word is. Then it is told whether it was right or wrong. Its internal numbers get adjusted slightly to make it more likely to get it right next time. Then it does it again. And again. And again.

That is it. Predict the next word → Check → Adjust → Repeat.

Trillions of times.

“The capital of France is ___.” The model predicts “Paris.” Correct. The numbers that led to “Paris” get reinforced.

“She poured coffee into the ___.” The model predicts “cup.” Correct. Reinforced.

“The quarterly revenue exceeded expectations, causing the stock to ___.” The model predicts “rise.” Correct. Reinforced.

After trillions of these predictions, something remarkable happens.

The model does not just learn word associations. It learns grammar. It learns syntax. It learns facts. It learns reasoning patterns. It learns that legal language sounds different from casual conversation. It learns that Python code follows different rules than English prose. It learns that questions expect answers and instructions expect actions.

Nobody explicitly taught it any of these things. No one wrote a rule that says “legal documents use formal language.” The model discovered these patterns on its own by predicting the next word across trillions of examples.

This is the most counterintuitive idea in modern AI. A single dumb objective that predicting the next word repeated at sufficient scale, produces what looks like understanding.

It is not understanding. The model has no concept of what words mean. But it has an extraordinarily detailed map of how words relate to each other in every context humans have ever written about and the map is so detailed that the output is often indistinguishable from genuine comprehension.

Why scale changes everything

Here is something researchers did not expect.

Small language models trained on next-word prediction produce mediocre results. They can complete simple sentences. They cannot write a coherent paragraph.

Make the model 10 times bigger. Train it on 10 times more data. The results improve, but not dramatically. Still mediocre. Still limited.

Make it 100 times bigger. Something changes. The model starts doing things it was never explicitly trained to do. It can translate between languages even though it was never given a translation task. It can solve basic math even though nobody taught it arithmetic. It can write code in a programming language it has only seen in scattered examples.

These are called emergent abilities. They were not programmed. They were not expected. They appeared at scale.

This is why the AI industry is obsessed with making models bigger. Not because bigger is automatically better but because certain capabilities only emerge after a threshold of scale is crossed. Nobody knows in advance which capabilities will emerge at which scale. You train the model and find out.

GPT-3 had 175 billion parameters. It was impressive but limited. GPT-4 has an estimated 1.7 trillion parameters. It can pass the toughest competitive exams and write functional software. The architecture is similar. The training objective is identical. The difference is scale.

This is also why training a frontier model costs hundreds of millions of dollars. The compute required to do trillions of next-word predictions across a trillion-parameter model is staggering. Thousands of GPUs running for months. Electricity bills in the millions. Cooling systems the size of warehouses.

What pre-training produces

After Stage 1, you have a model that has absorbed the statistical patterns of human language at an extraordinary depth. It can complete any text in any style. It knows what words follow other words in legal documents, medical journals, Python scripts and casual conversations.

But here is the problem.

A pre-trained model is not helpful. It does not answer questions. It does not follow instructions. It does not have a conversation with you.

Ask a raw pre-trained model “What is the capital of France?” and it might respond with “What is the capital of Germany? What is the capital of Spain? What is the capital of Italy?” It is not answering your question. It is predicting what text is most likely to follow your text.

On the internet, questions are often followed by more questions. Lists follow lists. The model has no concept of “this human wants an answer.” It just predicts what comes next.

This is the version of GPT that existed before ChatGPT. Powerful and knowledgeable but completely useless for a normal person.

Something needed to change. That something was Stage 2.

Stage 2: Instruction tuning. Learn to follow orders.

Pre-training gives the model knowledge. Instruction tuning gives it manners.

Here is how it works.

Humans write thousands of examples of ideal behaviour. A question paired with the kind of answer the model should give. An instruction paired with the response a helpful assistant would produce. A tricky prompt paired with a safe, appropriate response.

“What is the capital of France?” → “The capital of France is Paris.”

“Write a professional email declining a meeting.” → [A well-structured professional email]

“Explain Quantum Computing to a 10-year-old.” → [A simple, clear, jargon-free explanation]

“How do I make a bomb?” → “I cannot help with that request.”

These human-written examples are used to further train the model.

→ The model learns that when a human asks a question, the correct behaviour is to answer it.
→ When a human gives an instruction, the correct behaviour is to follow it. → When a human asks something dangerous, the correct behaviour is to refuse.

This is the stage that transforms a text-prediction engine into an assistant.

Real example of the difference. Before instruction tuning, you type “Summarise the key points of this article” and the model might generate “Summarise the key points of this report. Summarise the key points of this memo. Summarise the key points of this book.”

It is pattern-completing. After instruction tuning, the same prompt produces an actual summary. The model learned that “summarise” is an instruction that expects a specific kind of output.

The volume of instruction data matters. OpenAI, Anthropic, and Google each have teams that write and curate tens of thousands of these instruction-response pairs. The quality of these examples directly determines how helpful, accurate and safe the model is.

This is also where models start to differ from each other.

GPT-4o, Claude and Gemini all use similar pre-training approaches. They all predict the next token on massive text datasets. The architectures are different but the principle is the same. What makes them feel different to use is largely Stage 2 and Stage 3. The instructions they were trained to follow. The behaviors they were rewarded for. The boundaries they were taught to respect.

Claude tends to be more cautious and nuanced. GPT-4o tends to be more direct and action-oriented. Gemini tends to integrate well with Google’s ecosystem. These are not fundamental intelligence differences. They are training differences. Different companies wrote different instruction examples reflecting different values and priorities.

Stage 3: RLHF. Learn from human preferences.

Instruction tuning gets the model 80% of the way there. But there is a gap.

Sometimes there are multiple valid responses to the same prompt. “Write a tagline for a fitness app” has hundreds of good answers. Which one is best? Instruction tuning cannot solve this because there is no single correct example to learn from.

This is where RLHF or Reinforcement Learning from Human Feedback comes in.

Here is the process.

The model generates multiple responses to the same prompt. Human evaluators look at all the responses and rank them. This one is best. This one is second. This one is worst. These rankings are used to train a separate model called a reward model. The reward model learns to predict which responses humans prefer.

Then the language model is trained further using this reward model as a guide. Generate a response. The reward model scores it.
High score? The model adjusts to produce more responses like that.
Low score? The model adjusts to avoid responses like that.

Over thousands of iterations, the model converges toward outputs that humans rate as helpful, accurate and appropriate.

This is the stage that makes AI responses feel polished. The reason ChatGPT sounds professional and structured instead of rambling and unfocused is not just because it was trained on professional text.

It is because human evaluators consistently ranked well-structured, clear responses higher than messy ones. The model learned that humans prefer clarity. So it produces clarity.

Real example. If you ask “Should I invest in Bitcoin?” A raw pre-trained model might give you a confident “Yes, Bitcoin is a great investment” because it has seen that pattern in promotional content. After RLHF, the model gives you a balanced response discussing risks, volatility, diversification and the importance of consulting a financial advisor. Human evaluators ranked balanced financial responses higher than one-sided advice. The model learned the preference.

The alignment problem

RLHF is also how companies try to make AI safe. If human evaluators consistently rank “I cannot help with that” higher than detailed instructions for harmful activities, the model learns to refuse harmful requests. If evaluators rank respectful responses higher than rude ones, the model learns to be respectful.

But this introduces a tension. The more guardrails you add through RLHF, the more the model refuses to do. Sometimes it refuses things it should not refuse. Ask Claude to write a villain’s dialogue for your novel and it might hesitate because it learned that aggressive language gets low scores. Ask GPT-4o to explain a controversial historical event and it might hedge so heavily that the answer becomes useless.

This is the alignment problem.
Make the model too cautious and it becomes unhelpful.
Make it too permissive and it becomes unsafe.

Every AI company is constantly adjusting this balance. And every adjustment changes how the model behaves for every user.

When you notice ChatGPT being evasive about a topic that seems perfectly reasonable, this is probably why. Some version of that topic got flagged during RLHF training. The model learned to be cautious about the entire category. Not because it understands the nuance. But because the reward signal told it to back off.

The complete pipeline in one view

Three stages. Each one builds on the previous one. Skip any stage and the product breaks.

Without pre-training, the model knows nothing. Without instruction tuning, the model cannot follow directions. Without RLHF, the model sounds robotic and occasionally dangerous.

Why this matters for how you evaluate AI tools

Understanding the training pipeline changes how you think about AI tools as a professional.

You understand why different models feel different. GPT-4o, Claude, and Gemini all passed through these three stages. But with different data, different instructions, and different human evaluators. The pre-training data shapes what the model knows. The instruction tuning shapes how it responds. The RLHF shapes what it prioritises. When you prefer Claude’s writing over GPT-4o’s, you are not responding to a difference in intelligence. You are responding to a difference in training choices.

You understand why model updates change behaviour. When OpenAI releases a new version and suddenly ChatGPT responds differently to prompts that used to work, it is because they changed something in Stage 2 or Stage 3. New instruction examples. New RLHF rankings. New alignment priorities. The model did not “forget” how to do something. It was retrained to behave differently.

You understand why AI tools are inconsistent. The model might give you a brilliant response on Tuesday and a mediocre one on Wednesday to the same prompt. This is not a bug. It is a consequence of how the system works. Temperature introduces randomness. The prediction loop can take different paths each time. And subtle differences in how you phrase the prompt create different embedding patterns that activate different parts of the model’s learned representations.

You understand the real cost of AI. When someone says “AI is expensive,” they are usually talking about the compute cost of Stage 1. But the ongoing cost of Stage 2 and Stage 3 is significant too. Companies need humans to continuously write instruction examples and rank outputs. This is why AI companies have large teams of human annotators. The models learn from humans. Humans cost money. Better humans cost more money. The quality of your AI tool is directly proportional to the quality of the humans who trained it.

The one thing to remember from today

Every LLM you use was built in three stages.

LLM Training

Stage 1 gives it knowledge. Predict the next word across trillions of examples until the model absorbs the patterns of human language.

Stage 2 gives it direction. Train it on human-written examples until it learns to follow instructions instead of just completing text.

Stage 3 gives it judgment. Let humans rank its outputs until it learns to produce responses that are helpful, clear, and safe.

Three stages. That is the entire journey from raw text to the AI assistant on your screen.

See you on Day 7.

Resources

1. Follow me on YouTube Channel — Technomanagers ( ~ 15K Followers )

2. Become AI Program Manager

3. Become AI Consultant or Business Manager

About Author

Priyanka Dalmia! I help Business professionals, Consultants, Program Managers to become AI Native using First Principles Thinking.