It doesn’t. Faster typing hitting the same review, test, security, and deploy pipeline just moves the queue. The constraint didn’t disappear; it relocated — out of the individual’s inner loop and into the outer loop, the coordination surface, the paths between teams. And that surface is exactly what platform and developer-experience teams own.

So the AI-era question for platform teams isn’t “how do we give everyone a copilot.” It’s “what does the copilot need from us to be trustworthy at speed?”

Agents break without structure

I’ve argued before, in the CAR framework, that agentic AI fails not on reasoning but on structure. An agent with no guardrails submits the form before you’ve reviewed it. An agent with no visible progress runs for five minutes and dies with “unknown error.” More autonomy demands more structure — because users can’t trust what they can’t predict.

Coding agents are no different. Point one at an ambiguous codebase and it will invent its own way to make the change — a different way every time. The hazy path that a senior engineer quietly resolves, an agent papers over at scale. Ambiguity is the one thing agents handle worst, and it’s the exact thing a golden path removes.

That’s the reframe: a Golden Path is CAR for machines. It’s the structure that turns an agent’s autonomy into velocity you can trust.

Golden Paths, read through CAR

Context. An agent can only act well if it has what it needs. The platform team’s job is to shrink the context delta — machine-readable docs, well-structured repos, discoverable components (auth, logging, payments) it doesn’t have to reinvent. On the board, this is cognitive load: fewer contexts, fewer locations to touch. Low load for a human is low load for an agent.

Action. Not every action is equal. Filling a field is safe; merging, deploying, touching production is not. CAR insists irreversible steps get a human gate. For coding agents, your pipeline is that gate — CI checks, policy-as-code, security scanning, review. The golden path encodes which actions are allowed and which stop for consent, so speed never becomes recklessness.

Response. Every result should feed the next cycle. A failed test, a scan finding, an observability signal — these are the responses that sharpen the agent’s next move. Platform teams that instrument the outer loop aren’t just measuring it; they’re closing the loop the agent learns inside.

Context, Action, Response — the same loop that makes an agent’s experience trustworthy is the loop that makes an agent’s code trustworthy. Platform engineering builds it.

What this means on Monday

Make your golden paths agent-consumable — templates and policies an agent can execute, not PDFs it can’t read. Put them behind one interface (your IDP) that humans and agents both consume. Automate the outer loop hard, because that’s where the constraint now lives. Kill the ticket queue in front of the loop; a ticket in front of an agent-speed inner loop is the most expensive bottleneck you own.

And measure flow, not output. Lines and commits were always the wrong metric — now they’re actively misleading, because generation inflates exactly those numbers while telling you nothing. Track mean time to make a change, time to discover the path, and how often work moves backward. Those survive AI because they measure friction, not typing.

Structure creates freedom

The irony of agentic AI holds for coding agents too: more autonomy requires more structure. The copilot gave every developer freedom to move fast. The golden path is what turns that freedom into velocity that actually ships — and it’s the platform team’s to build.

That’s the whole job in the AI era. Not accelerating the developer — the copilot already did that. Fast-forwarding them from code to product value.

The reality is that fine-tuning is not dead. It has simply found its true purpose.

Beyond “The AI Model”

We need to stop treating “The Model” as a singular commodity. The market has splintered into specialized tools that far outperform the generalist models of last quarter.

While many enterprises are still running Llama in production, the cutting edge has moved to specialized architectures:

• DeepSeek-R1 has redefined the open-source standard for reasoning.

• Kimi K2 supports 256K tokens context.

• Llama 4 represents a major architectural shift to MoE,

You are no longer picking the best model. You are picking the best engine for a specific vehicle.

Shortfalls of tuning

Fine-tuning was positioned as the way to make models “yours”, teaching them your domain, your style, your knowledge. In practice, it has proven expensive and fragile.

The cost is prohibitive for frequent updates. Every time your product changes, your policies update, or your market shifts, you need another training run. Furthermore, fine-tuned models often overfit to training patterns while failing to generalize. You train it on Q3 financial data, and it struggles with Q4’s new revenue streams.

The real issue: fine-tuning bakes knowledge into weights that can’t be updated without retraining. It’s perfect for stable patterns (brand voice, code syntax) but fundamentally mismatched for dynamic knowledge.

The Future of RAG is “Judging”

This is the strategic pivot you should expect. RAG is evolving from a Retrieval mechanism into a Verification layer.

Early RAG systems followed a simple “Fetch then Generate” workflow. The emerging pattern we’re seeing in production agentic systems moves to “Think, Draft, then Verify.” In this workflow, the model generates an answer first, then uses RAG to validate its output against authoritative sources, correcting hallucinations before the user ever sees them. This turns RAG into a compliance and accuracy tool rather than just a search bar.

Think of it as the difference between giving a model a textbook during an exam versus having it write the answer first, then check its work against the textbook.

The Analytical Gap

You may have noticed that both fine-tuning and RAG struggle with deep analysis and math. This isn’t a failure of your data; it’s a failure of the architecture.

Standard Transformers are prediction engines—they guess the next word, they don’t “think.” No amount of RAG data can teach a model to calculate a derivative or analyze a P&L statement if the underlying reasoning architecture is missing. For these tasks, you don’t need more data; you need a model architected for Reasoning, like the DeepSeek-R1 lineage, which generates an internal chain of thought before outputting a single token.

This is why reasoning models excel at competition-level math and coding challenges while standard models struggle—even when both have access to the same training data.

Solving the Root Cause: The Post-Transformer Era

Why do we even have the “Fine-tune vs. RAG” debate? It exists because Transformers have a fundamental flaw: they have “frozen brains.” They cannot learn after training, and they cannot remember anything outside their limited context window. RAG and fine-tuning are just expensive band-aids for this limitation.

New architectures are finally addressing the root cause.

Baby Dragon Hatchling (BDH)

Pathway’s BDH represents a fundamental shift. It is a post-Transformer architecture that mimics biological neural networks through scale-free, locally-interacting neuron particles. Unlike Transformers, BDH’s internal structure adapts during interaction, allowing it to generalize over time and maintain coherent reasoning across extended sessions. You don’t need to fine-tune it to teach it your project status; it adapts its neural pathways based on repeated interactions. This natively solves the memory and generalization problems that RAG attempts to patch.

The catch? BDH is still in early research stages (released September 2025), showing promising results at small scale but not yet proven in production environments.

State Space Models (SSMs)

Think of SSMs as the efficiency experts. Models like Mamba allow for incredibly long context windows—up to million-token sequences—without the exponential cost of Transformers. They achieve linear scaling in sequence length with 5× faster inference than comparable Transformers.

SSMs are ideal for “reading” entire codebases or legal archives in one go, potentially reducing the need for chunking and indexing in some RAG use cases. However, they complement rather than replace RAG—long context solves the “reading” problem, but not the semantic retrieval and ranking challenges.

The Path Forward

The “Fine-tune vs. RAG” debate was always a false choice. The real question is: What cognitive capability does your use case actually need?

Three principles for 2026:

1. Match the architecture to the task. Stop forcing Transformers to do everything. If you need pattern replication (brand voice, formatting), fine-tune. If you need current information retrieval, use RAG. If you need deep reasoning, use reasoning models. If you need continuous adaptation, explore post-Transformer architectures.

2. Combine approaches strategically. The best production systems layer multiple techniques. A customer service agent might use fine-tuning for brand voice, RAG for policy lookup, and reasoning models for complex problem-solving—all in one workflow.

3. Stay architecture-aware. Transformers dominated 2023-2024, but the landscape is fragmenting. SSMs, reasoning models, and post-Transformer architectures each excel in different domains. Your competitive advantage lies in knowing which tool to deploy where.

The industry spent 2024 asking “Should I fine-tune or use RAG?” In 2026, we’ll be asking “Which cognitive architecture does this problem actually require?” That’s the right question.

I was fortunate enough to build an agentic flow back in 2018. The average cost was less than $0.0002 a request. I wanted to take a moment to throw some light on how it was and why most devs and engineering teams are ending up complicating. I hope this perspective helps and leaves some teams inspired to navigate the asks from their stakeholders with ease.

Stayology was a Travel Tech platform that enables users to search for Trips and book for matching flights, accommodations and activities. We did this for 50,000 destinations at 170+ countries. At the time, I was leading engineering and product.

As with travel apps, the amount of data that was to be collected from users just to show matching results in overwhelming, espcially when a new app asks for so much information just to try it. To give you a glimpse of the challenge, a travel search needs

• Origin - city and airport

• Destination - city and airport

• No. of travellers - adults, kids, infants

• Start date, end date - May be more if it’s a multi-destination trip

• What all do you want - flights, stays, activites

To add to the complexity, users had to decide on what activity to fit in at what time slot during the trip. If we were to compare it with how the requirements are shared with a travel agent, it was over a phone call, using speech. We ran an experiment and did a prototype and to our surprise. We didn’t do agentic AI because it was a trend but, it proved to solve a real problem of collecting inputs form users and the time it takes. We didn’t even know it was called agentic. 😂

What AI?

If it was text, we needed a model that can understand natural language. Just about the time, Microsoft launched LUIS, a framework for training LLMs. LUIS was Microsoft’s natural language understanding service, allowing us to classify user intents and extract entities like airports and dates.”

How did we build an agentic flow?

• Collect speech from the user on a mobile app

• Parse speech to text

• Validate the text and send the text to LUIS service - We trained a NLP model on LUIS that can understand and classify multiple intents. We trained it on Airport Codes, destination names, it was well capable of understanding dates

• LUIS service parses the text and classifies what Origin, Destinations, travellers, start and end dates and sends back a JSON

• The JSON was parsed and used to build a request/payload for our search API. Sure, we had to write some exception handlers and logic to parse it well

• and , when the search API was hit, we had results on the screen

Value delivered

• We were new in the market, we wanted to show some radical shift in how travel booking experience can be. This enabled us to take away the pain of inputting several inputs, one after the other. If there’s a miss, the user could always edit them on the results screen.

• Time taken to capture inputs down to 2.5 Seconds

• Focus was on results.

Running costs

• It cost $0.00015 or less for the entire lifecycle of the request.

• Breakdown - 0.00012 per LUIS and our API costs were minimal

• Speech to Text parsing was done locally on the phone and at 0 cost

Time to live(TTL)

• We were live in 2 weeks!

• LUIS enabled us to train the model in less than 2 days

• We were a team of super productive engineers and were able to orchestrate the flow within a week

• Another week for testing and validation

It doesn’t really have to be that complicated and you can do it too if you focus on what matters to users and evaluate different opportunities to add value across the journey.

So, what exactly is agentic AI?

1. You take an input from the user

2. You have an AI Model evaluate it and give your system some meaningful data to act on

3. Plug that data back into your system

4. Deliver the value your system/product has to offer

It doesn’t have to cost you a bomb and host a Large Language Model to deliver agentic AI.

Focus on what truly matters for user experience, build iteratively, and let AI serve as an enabler—not a complication. If you’re building agentic workflows today, ask yourself: Is the complexity adding value, or can you simplify while delivering the same impact?

One might argue that AI is radical and we need to do some fancy things. Yes, it is radical as a technology but users love it when it really solves a pain point.

I asked two AI browser agents to fill out a form, and both failed in ways that expose this gap perfectly.

Agent 1 (Comet) filled every field correctly. Then submitted the form—without asking. I told it to fill the form, not submit it. It couldn’t distinguish between a routine action and an irreversible one that required my consent.

Agent 2 (Atlas) took over five minutes with no visible progress. It eventually failed with “unknown error.” I had no idea what it was attempting, what was blocking it, or whether it was still running.

These aren’t edge cases. They’re the norm. And they reveal a structural gap in how we build agentic AI today.

The Missing Layer

Frameworks like ReAct (Reason + Act) and OODA (Observe-Orient-Decide-Act) are excellent at structuring how agents think. They power the reasoning loop—when to gather information, when to act, when to reassess. But they say nothing about what the user experiences during that loop.

That’s the gap. Every agent team reinvents answers to the same three questions:

Context strategy: What information is missing? Do we ask the user, search for it, infer from history, or pull from profile data?

Action logic: Which actions align with the task? Which ones are reversible? Which require explicit human approval before execution?

Response design: After acting, do we proceed to the next step, present options, gather more context, or pause for confirmation?

Comet’s failure was an action logic gap—it treated form submission the same as filling a text field, with no distinction between low-stakes and high-stakes actions. Atlas’s failure was a response design gap—no progress signal, no fallback, no transparency about what was happening.

Traditional UX design doesn’t solve this. Traditional software is deterministic: users click A and reliably see B. Every path is pre-scripted. Agentic AI is probabilistic: the agent decides what to do next based on context, and the path changes dynamically. We need structure that accounts for this shift—structure that works for both the builders planning these experiences and the AI executing them.

CAR: Context, Action, Response

CAR is a systematic loop that moves users from intent to task completion. Each cycle sharpens the next: responses feed back into context, actions become more precise, and the agent converges on what the user actually needs.

CONTEXT — Does the agent have everything it needs to act? Identify the delta—what’s missing—and determine the acquisition strategy: ask, search, reference history, or infer from profile. When context grows noisy, fall back to discovery mode and ask one decisive question to reset clarity.

ACTION — Rank possible actions by alignment with task success and user risk. Continuously evaluate: are we progressing toward completion? Does this action require human confirmation? Irreversible steps—payments, deletions, submissions—always require explicit consent.

RESPONSE — Decide the next move: proceed to the next segment, acquire additional context, or pause for human approval. Each response enriches the context for the next cycle, creating compounding momentum toward task success.

The key insight: CAR is not linear. It’s a feedback loop. Every response refines context, which sharpens the next action, which produces a better response. This compounding effect is what drives both task completion and user trust.

How CAR Complements Existing Frameworks

CAR doesn’t replace ReAct or OODA—it layers on top of them.

ReAct provides the reasoning loop (Thought → Action → Observation). CAR structures what users see during each cycle: what context is visible, when to automate versus ask, and how to present results.

OODA provides speed and adaptability. CAR operationalizes it for the experience layer by making response design a first-class outcome—one that feeds back into context and creates compounding trust.

Planner-executor patterns define agent architecture. CAR defines the UX boundaries—when to enforce human-in-the-loop checkpoints, where to surface progress, and how to handle failures gracefully.

Put simply: agent frameworks make agents intelligent. CAR makes them trustworthy.

CAR in Practice: A Shopping Agent

Here’s how CAR structures a simple shopping task. The goal isn’t to optimize a metric—it’s to ensure predictable reasoning, visible progress, and human-in-the-loop trust at every step.

User prompt: “Buy a white loose-fit, size M t-shirt under $40.”

Loop 1 — Discover (Context)

The agent parses explicit requirements (white, loose-fit, M, under $40) and identifies one ambiguity: priority. Does the user optimize for price, delivery speed, or quality?

It asks one clarifying question—not three. The user responds: “Budget.”

Context is now complete. The agent proceeds.

Loop 2 — Search (Action)

The agent normalizes terms, runs parallel searches across multiple stores, and scores results against the constraint set. It surfaces 5–7 options, each tagged with price, fit, and availability.

The user sees progress: a scored list, not a loading spinner.

Loop 3 — Evaluate (Response → Context)

The response from Loop 2 feeds back into context. The agent compares shortlisted options, validates size and color stock, and narrows to the best match.

It nudges: “This option matches all your criteria. Add to cart?”

Loop 4 — Checkout (Action → HITL Gate)

The agent prefills the checkout form, verifies the total, and stops. It does not submit. It presents a confirmation checkpoint: item, price, shipping, total.

The user confirms. The agent completes the purchase.

What CAR prevented: The agent reaching checkout and submitting payment without consent—which is exactly what happened in my baseline test run. The payment gateway demanded credentials before the agent halted, but that was luck, not design.

What success looks like: Item in cart. User saw progress at every step. Zero surprise actions.

The CAR Trace: Making Agent Behavior Auditable

One of the practical benefits of CAR is that it produces a structured trace—a log of what the agent knew, what it did, and what the user saw at each step. This makes agent sessions legible across product, design, and engineering.

Event types: context_gather, clarify, search, navigate, decision, response_display, hitl_check, halt.

[
  {
    "segment": "Discover",
    "context": ["intent=tshirt", "color=white", "fit=loose", "size=M"],
    "action": ["clarify"],
    "response": ["priority=budget"]
  },
  {
    "segment": "Search",
    "context": ["priority=budget", "price_ceiling=40"],
    "action": ["multi-site search", "filter", "score"],
    "response": ["5 options displayed"]
  },
  {
    "segment": "Checkout",
    "context": ["selected_sku=ABC123"],
    "action": ["prefill", "verify_totals"],
    "response": ["hitl_confirm"],
    "status": "awaiting_consent"
  }
]

You can debug failures purely from this trace—without instrumenting metrics. When an agent misbehaves, you can pinpoint whether the breakdown was in context (wrong or incomplete information), action (wrong decision or missing guardrail), or response (poor communication to the user).

Implementation Playbook

For teams adopting CAR, the operationalization breaks down into six areas:

Journey-first roadmap. Map end-to-end segments (e.g., “Shop Product”) with clear entry and exit conditions. Define CAR requirements at each node—what context is needed, what actions are allowed, and what responses are expected.

Context capture by design. Use conversational questions, smart defaults from history, and progressive disclosure. Capture only what drives decisions. When context bloats, ask one decisive question to reset.

Action policies and guardrails. Define allowed tools per segment, escalation logic, HITL gates for irreversible steps, and fallback behaviors when the agent is stuck or timing out.

Response patterns. Standardize option cards, clarifying question formats, progress indicators, and error handling. Consistency builds trust across sessions.

Instrumentation. Log available context, actions attempted (with success/failure), responses shown, and user reactions. This becomes the dataset for improving the loop.

Operating cadence. Weekly reviews of segment drop-offs. Ship one CAR improvement per week. A/B test response patterns against task completion and user satisfaction.

How CAR Works with ReAct and OODA

CAR doesn’t replace existing agent frameworks—it complements them by adding the user-experience layer:

ReAct (Reason+Act) provides the reasoning loop: Thought → Action → Observation. CAR structures what users see during each cycle—what context is visible, when to automate vs. ask, how to present results and gather feedback.

OODA (Observe-Orient-Decide-Act) provides speed and adaptability. CAR operationalizes it for UX by making response design a first-class outcome that feeds back into context, creating compounding trust.

Why this matters: Agent frameworks make agents intelligent. CAR makes them trustworthy, transparent, and delightful. Together, they create agents that work and feel great.

Structure Creates Freedom

There’s an irony in agentic AI: more autonomy requires more structure. Agents have freedom to reason, navigate, and act—but without structure, that freedom becomes chaos. Users can’t trust what they can’t predict, and agents can’t build trust without consistent behavior at critical moments.

CAR provides that structure. It’s a loop—responses feed back into context, context sharpens actions, actions produce better responses—and that compounding dynamic is what drives both task success and user trust.

This isn’t just a framework for better agent experiences. It’s the layer that makes human-AI collaboration actually work.

I built CAR from shipping production agentic systems. If you’re building agents and hitting similar gaps—trust failures, invisible progress, consent violations—I’d like to hear how your team is solving them.

The future of AI isn’t just smarter models. It’s better structured experiences. CAR is how we get there.

They’re also optimizing for the wrong metric, solving for yesterday’s problem, not tomorrow’s opportunity.

Here’s the trillion-dollar question nobody’s asking: If your sales team generates $1 billion in revenue and AI tools save them 10% of their time, how does cutting 10% of your workforce make sense? That’s not optimization — that’s self-sabotage.

Misguided KPIs of “AI Efficiency”

In the example above, the sales teams save about 10% of the time with AI assistance in automated prospecting, smart lead scoring, and intelligent follow-ups.

The Fool’s Math:

• 10% time saved = 10% headcount reduction

• Fire 10 people

• Save $2 million in salaries

• Account for the “efficiency”

The Growth Math:

• 10% time saved = 10% more capacity

• Same 100 people now pursue 10% more opportunities

• Generate $1.1 billion in revenue (10% growth)

• Same opex, $100 million more revenue

• Actually build a growing business

The difference? One approach thinks like a cost accountant that is eager to capture and optimize the cost to operate. The other thinks like a CEO who wants to win. Which one would you rather be?

In reality, the gains can be as high as 300% for sales or may be more depending on how effectively your teams put AI to use. Engineers for example are able to 3x to 10x their capacity to build things.

Let’s apply that to the cloud tech

Here’s what makes this cost-cutting begins to feel more short-sighted: The cloud computing market was at $750 billion in 2024 and poised to hit $2.2–2.4 trillion by 2030. That’s a CAGR of 20%+.

Let that sink in. The market is TRIPLING in six years, and tech companies are laying off the very people who could help them capture that growth.

Let’s put this in perspective: The cloud market is expanding by $1.5 trillion over six years. That’s not the total market — that’s just the growth. Cloud companies laying off engineers and salespeople to save $10–20 million are essentially trading millions in savings for billions in lost opportunity. Even a small player capturing just 0.1% of that expansion would gain $1.5 billion in new revenue.

How can anyone justify reducing capacity when the pie is tripling in size?

Teams Are Systems, Not Spreadsheets

When you cut 10% of a team, you don’t just lose 10% capacity — you lose institutional knowledge, break workflows, and damage morale. The evidence is already in:

Duolingo fired translators and writers for AI, only to find the AI content was “boring” and full of errors. They’re now rehiring. Klarna claimed its AI replaced 700 customer service agents, then reversed course, with the CEO admitting they went “too far” with automation.

The pattern is clear: Companies that treat teams as interchangeable parts learn expensive lessons about what AI can’t replace.

The Real Impact of AI: Capacity Multiplication

Companies that get it right understand a fundamental truth: AI doesn’t replace human capability — it multiplies it. When you give AI tools to your team, you’re not creating redundancy; you’re creating superhumans.

• Sales teams with AI can qualify leads faster, personalize outreach at scale, and focus on high-value relationship building

• Engineers with AI can ship features faster, catch bugs earlier, and tackle more complex problems

• Marketing teams with AI can test more campaigns, analyze more data, and create more targeted content

• Customer success teams with AI can prevent more churn, identify more upsell opportunities, and deliver more value

Each person becomes capable of delivering 10% to 1000% more value. But only if they’re still there to use these tools.

And here’s the kicker — AI tools cost roughly $300 per employee per month at the upper median. That’s $3,600 per year to potentially 10x someone’s output. A software engineer making $200,000 who becomes 3x more productive with AI? That’s $400,000 in additional value for a $3,600 investment. The ROI is over 11,000%.

Yet, companies are eliminating the $200,000 engineer to save costs, instead of spending $3,600 to triple their output.

The Only Exception That Proves the Rule

There’s only one scenario where AI-driven workforce reduction is logical: when your capacity genuinely exceeds your total addressable market (TAM) or achievable market share.

But here’s the thing — none of the major tech companies laying off thousands of employees fit this criteria. They’re all in exponentially growing markets. The cloud market alone is adding $1.5 trillion in new opportunity. AI itself is creating entirely new market categories.

So why are they cutting? Because they’re measuring the wrong thing — the cost to serve business instead of the opportunity to serve.

The Strategic Arbitrage of the Decade

While your competitors are laying off experienced staff to “save costs,” they’re creating the greatest talent and market opportunity in tech history.

Think about what’s actually happening:

• They cut 20% of staff → Their capacity shrinks while markets grow 20% annually

• They lose institutional knowledge → Years of customer relationships and product expertise walk out the door

• They damage morale → Their remaining talent starts looking for the exits

• They signal weakness → Customers and investors see a company in retreat, not growth

Meanwhile, if you maintain your workforce and add AI capabilities, you’re not just preserving capacity — you’re multiplying it at the exact moment your competitors are shrinking theirs.

This isn’t theoretical. In every market downturn, the companies that maintained capacity while others cut emerged as the dominant players. This time, with AI as a multiplier, the gap will be even more dramatic.

The $100 Billion Math Problem

Let’s quantify what’s really at stake here:

What the industry thinks it’s saving:

• 150,000 tech workers laid off × $150,000 average salary = $22.5 billion “saved”

What the industry is actually losing:

• Cloud market expansion 2024–2030: $1.5 trillion

• Even capturing just 7% of that growth: $100+ billion

• ROI of these layoffs: Negative 444%

That’s not a typo. For every dollar “saved” in salaries, companies are potentially losing $4.44 in market opportunity.

And this is just the cloud market. Add in AI services, edge computing, quantum, and other emerging markets, and we’re talking about missing out on the greatest wealth creation opportunity in human history — all to make quarterly earnings look better.

The Startup Lesson

Every successful startup knows this truth: When you’re able to sell and improve margins simultaneously, you’re scaling toward profitability. You don’t achieve sustainable growth by cutting capacity in growing markets — you achieve it by maximizing output while controlling costs.

The formula is simple:

• Fixed costs + Variable efficiency = Exponential returns

• Not: Reduced costs + Reduced capacity = Slow death

Reskilling Is Easy, Rebuilding Is Hard

One of the most common objections to maintaining headcount is “but what if people can’t adapt to AI?” This is nonsense. AI is designed to work with natural language. If someone can write an email, they can use AI.

For those struggling:

• Provide clear, simple frameworks

• Offer hands-on training

• Pair them with AI-savvy colleagues

• Give them time to adapt

The cost of reskilling is minimal compared to the cost of rebuilding teams, relationships, and institutional knowledge later.

The Bottom Line

Tech companies laying off employees because AI makes them “more efficient” are making the same mistake as a farmer eating his seed corn. Yes, you’ll save money this quarter. But you’re destroying your capacity to grow when the market is literally doubling in size.

The winners in the AI era won’t be the companies that use AI to do the same with less. They’ll be the companies that use AI to do exponentially more with the same.

Stop measuring cost savings. Start measuring capacity gains.

Stop thinking like an accountant. Start thinking like a conqueror.

The market is growing. Your tools are getting better. Your only question should be: How much of this growth can we capture?

Because if you’re cutting staff while your market is exploding, you’re not being efficient. You’re being a fool.

Remember: Your competitors’ layoffs are your opportunity. While they’re “optimizing” themselves into irrelevance, you can be building the capacity to own the future.

Is Agentic new? How did we do it back in 2018

AI, Agentic and LLMs workflows are all the rage. With billions being poured into it and all the hype, there’s a lot of disorientation for engineering and product teams about what truly matters and what components to use to build the right experience.

I was fortunate enough to build an agentic flow back in 2018. The average cost was less than $0.0002 a query. I wanted to take a moment to throw some light on how it was and why most devs and engineering teams are ending up complicating. I hope this perspective helps and leaves some teams inspired to navigate the asks from their stakeholders with ease.

Stayology was a Travel Tech platform that enables users to search for Trips and book for matching flights, accommodations and activities. We did this for 50,000 destinations at 170+ countries. At the time, I was leading engineering and product.

As with travel apps, the amount of data that was to be collected from users and the date to

• Origin city and airport

• Destination city and airport

• How many - adults, kids, infants

• Start date, end date - 2 inputs

To add to the complexity, users had to decide on what activity to fit in at what time slot during the trip. We didn’t do agentic AI because it was a trend but, it proved to solve a real problem of collecting inputs form users and the time it takes. If we were to compare it with how the requirements are shared with a travel agent, it was with over a phone call, using speech. We ran an experiment and did a prototype and to our surprise

What AI?

If it was text, we needed a model that can understand natural language. Just about the time, Microsoft launched LUIS, a framework for training LLMs. LUIS was Microsoft’s natural language understanding service, allowing us to classify user intents and extract entities like airports and dates.”

How did we build an agentic flow?

• Collect speech from the user on a mobile app

• Parse speech to text

• Validate the text and send the text to LUIS service - We trained a NLP model on LUIS that can understand and classify multiple intents. We trained it on Airport Codes, destination names, it was well capable of understanding dates

• LUIS service parses the text and classifies what Origin, Destinations, travellers, start and end dates and sends back a JSON

• The JSON was parsed and used to build a request/payload for our search API. Sure, we had to write some exception handlers and logic to parse it well

• and , when the search API was hit, we had results on the screen

Value delivered

• We were new in the market, we wanted to show some radical shift in how travel booking experience can be. This enabled us to take away the pain of inputting several inputs, one after the other. If there’s a miss, the user could always edit them on the results screen.

• Time taken to capture inputs down to 2.5 Seconds

• Focus was on results.

Running costs

• It cost $0.00015 or less for the entire lifecycle of the request.

• Breakdown - 0.00012 per LUIS and our API costs were minimal

• Speech to Text parsing was done locally on the phone and at 0 cost

Time to live(TTL)

• We were live in 2 weeks!

• LUIS enabled us to train the model in less than 2 days

• We were a team of super productive engineers and were able to orchestrate the flow within a week

• Another week for testing and validation

It doesn’t really have to be that complicated and you can do it too if you focus on what matters to users and evaluate different opportunities to add value across the journey.

So, what exactly is agentic AI?

1. You take an input from the user

2. You have an AI Model evaluate it and give your system some meaningful data to act on

3. Plug that data back into your system

4. Deliver the value your system/product has to offer

It doesn’t have to cost you a bomb and host a Large Language Model to deliver agentic AI.

Leadership in startups often oscillates between two extremes: delegation and micromanagement. While delegation fosters autonomy and empowerment, it can lead to confusion without proper context. Conversely, micromanagement might ensure short-term success but often stifles creativity and morale.

Founder Mode

Paul Graham's orginially wrote about Founder Mode defining it as a founders' active engagement with their teams, emphasizing direct involvement over traditional management to foster effective decision-making and a strong organizational culture.

Such style of leadership emerges as a balanced approach that empowers teams while providing necessary direction. Rooted in the founder's mindset, this model emphasizes vision, ownership, and context-sharing to drive results.

The Power of Context

1. Why Context Beats Control
   Great leaders go beyond merely managing tasks; they provide essential context. When teams understand the bigger picture, they can make decisions that align with organizational goals, fostering accountability and reducing dependency on leadership.

2. Building and Sharing Context
   Constant communication is vital for establishing context. Leaders must ensure their teams understand:

   • The Vision: What are we trying to achieve?

   • The Priorities: What matters most right now?

   • The Constraints: What should we avoid or be cautious about?

   While frameworks like OKRs aim to achieve this clarity, they often fall short due to execution and alignment becoming siloed among multiple managers and teams, sometimes exacerbated by poor organizational structure.

Avoiding Common Leadership Traps

1. The Micromanagement Spiral
   Micromanagement often starts with good intentions—ensuring quality or meeting deadlines—but can lead to burnout for both leaders and teams.
   To avoid this:

   • Set clear expectations upfront.

   • Trust teams to deliver, intervening only when necessary.

2. The Delegation Trap
   Delegation without context can result in misaligned outcomes.
   Leaders should:

   • Regularly review progress.

   • Ask clarifying questions instead of dictating solutions.

Implementing Founder Mode Leadership

1. Decision-Making Frameworks
   Founder Mode thrives on empowering teams while maintaining strategic alignment through frameworks that clarify:

   • The Why: Define the purpose and desired outcomes.

   • The What: Specify goals and metrics for success.

   • The How: Allow teams to determine execution strategies.

2. Measuring Success
   Effective leadership creates an environment where teams succeed. Key indicators of successful Founder Mode leadership include:

   • Teams making aligned decisions without constant input.

   • Improved team morale and ownership of outcomes.

   • Sustainable achievement of organizational goals.

Founder Mode Leadership offers a powerful framework for modern teams by combining the structure of micromanagement with the freedom of delegation, anchored by context. By focusing on vision, alignment, and shared understanding, leaders can empower their teams to excel.

Are you ready to lead with context?

Subscribe now