I’m starting a YouTube channel.

And I’m changing what this newsletter is about.

Not because “new year, new me.”

Because I realized something I should have known earlier:

I’ve been hiding behind the tech.

Technology is fascinating. It’s a lever. It’s genuinely powerful.

But it’s not the thing I care about most.

The thing I care about is building something real. And helping people do the same without making the expensive mistakes I made.

So I’m shifting gears.

Why I’m really doing this

Here’s the truth.

I spent 2018-2021 burning through my savings, my health, and my confidence building a startup that didn’t survive COVID.

I spent 2021-2025 recovering at Microsoft. Rebuilding. Learning to be okay again.

And now I’m back in it — as a Founding Engineer at a stealth AI startup.

But this time is different.

Because this time, I’m not hiding.

I spent months writing about Agentic AI because it felt safe. Technical. Interesting enough to justify a newsletter without getting too personal.

But every time I wrote about “multi-agent orchestration” or “tool-calling patterns,” I knew I was dancing around what I actually wanted to say:

Startups are hard. But they’re learnable. And I wish someone had shown me the real path before I paid full price for every lesson.

So that’s what I’m doing now.

What I’m actually building toward

I don’t want to be an AI expert.

I want to be the person who made the mistakes so you don’t have to.

The person who lost a lot of money learning how to build a runway properly.

The person who burned out hard and came back with a system.

The person still in the trenches — not teaching from the mountaintop, but documenting from the climb.

That’s what this newsletter becomes.

And that’s what the YouTube channel is.

Because here’s what I realized:

If I want to help people, they need to find me first.

And right now? I’m invisible.

I’ve been writing in a corner of the internet, sharing thoughts with a small group, staying comfortable.

But comfortable doesn’t help anyone.

So 2026 is about visibility.

Not because I want to be famous.

But because the thing I’m building — both my company and this content — only works if people actually see it.

YouTube and Substack aren’t the goal. They’re tools for that visibility.

Just like AI isn’t the goal. It’s the tool for building faster.

The goal is the same:

Build something real. Help people do the same. Don’t hide.

The real context I can’t ignore

I co-founded Simplified Automation as CTO in 2018. We scaled to real revenue. We moved fast.

Then COVID hit.

And I made every classic founder mistake:

• Burned substantial personal capital trying to outrun reality

• Pushed through exhaustion like it was “resilience”

• Ignored the warning signs until burnout broke me

That chapter ended.

I spent four years at Microsoft Teams as a Software Engineer. Not because I gave up on startups. But because I needed to recover. To rebuild. To learn how to do this without destroying myself.

Now I’m back.

Founding Engineer at a stealth AI startup. Writing every week. Starting a YouTube channel today.

And this time, I’m not doing it quietly.

Because the mistakes I made were expensive. And if sharing them helps even one person avoid the same pain, it’s worth being visible.

What this newsletter becomes

Here’s the new spine:

Founder thinking, from someone still building.

Still practical. Still tactical. Still honest.

But less hiding behind AI theory.

More startup reality.

This is for you if you want to:

• Build your first startup without losing everything in the process

• Join an early-stage company and actually thrive

• Transition from corporate to startup chaos with a plan

• Learn from expensive mistakes without paying full price yourself

I’m not teaching from the finish line. I’m documenting from the middle.

What stays the same

The things that matter won’t change:

Real experience. Not guru advice. I’ll share what I actually did, what worked, what failed, and what I’m still figuring out.

Simple language. No buzzwords. No jargon without translation. If a 16-year-old can’t understand it, I’ll rewrite it.

Honest about the cost. Startups are incredible. They’re also brutal. I’ll talk about both.

And yes — AI stays in the conversation.

But it shows up as a tool in the stack. Not the identity of the newsletter.

You’ll see:

• How founders use AI to move faster with fewer people

• What to automate vs what to obsess over

• How to ship with leverage without building fragile systems

• Real examples from building in production

AI is still here. It’s just properly placed.

What changes immediately

1) The topics widen

Less narrow AI deep dives. More operator reality:

• How to quit your job without destroying your finances

• What to look for in an early-stage team before you join

• Product truth vs founder delusion

• How to balance a job + startup without lying to yourself

• Execution systems that survive chaos

• What I learned spending my own money vs building with investor capital

2) The content connects

I’m converging the newsletter with the YouTube channel.

Because I was splitting my thinking across too many places. And that creates noise.

Same ideas. Different formats.

Newsletter = the written version, the behind-the-scenes context, the operator notes that don’t fit in 8-10 minutes.

YouTube = the lessons, the stories, the frameworks, delivered like I’m talking to you over coffee.

Both pulling from the same source: what I’m actually learning while building.

3) The tone gets more direct

I’m done hedging.

Early-stage startup life punishes vague thinking. So I’m going to have stronger takes.

Not to be edgy. But because I’ve paid for these lessons and I’m not going to water them down.

Why I’m starting a YouTube channel

Because writing isn’t enough anymore.

I can write the best newsletter in the world and still be invisible.

So I’m showing up on camera. Weekly. Talking directly to the people I want to help.

Not polished. Not scripted into corporate-speak. Just real.

The goal is simple:

Make you feel like you can do this.

Not “this sounds impossible.”

Not “I guess I’m not cut out for startups.”

But: “Yes, I can do this — if I take the right steps.”

That’s the promise.

And if you want to see what that looks like, check out this video.

Here’s what I need from you

If this shift resonates, I need you to do something:

Make me visible.

Share this post. Forward it to someone building or thinking about building. Drop a comment with what you want to see more of.

And if you want the video version of these ideas — real stories, real lessons, no fluff — subscribe to the YouTube channel.

Because here’s the thing:

I can make all the content in the world. But if no one sees it, it doesn’t help anyone.

So help me help people.

2026 is about visibility. For me. For you. For anyone trying to build something real.

Let’s do this together.

Subscribe on YouTube

Let’s build. Out loud. Where people can see it.

— Ishmeet

P.S. — If you’re reading this and thinking “I want to make a similar shift but I’m scared,” reply to this email. I read and respond to all of them. Let’s talk about what’s holding you back.

“Why would we pay 10x more for a model that’s 5–10x slower?”

On paper, the choice seems obvious: take the fast, cheap model. Sub-second latency, lower bill, easier to justify in a sprint review.

But here’s how that decision often plays out in real teams:

You pick GPT-5-mini for a critical workflow because “it’s 10x cheaper and way faster.” Three weeks later, you’re drowning in error correction, manual reviews, and edge cases the fast model keeps missing.

Meanwhile, another team that chose OpenAI’s GPT-5-Pro — even though it’s 10x more expensive and 5–10x slower per request — ships their production system in half the time. Their advantage isn’t magic. It’s that they understand a simple truth most engineers miss:

In production, the speed that matters isn’t inference latency. It’s time to reliable output.

This isn’t theory. It’s what’s playing out right now across engineering teams navigating 2025’s biggest AI architecture decision.

The Two Paths Diverging in Production

Fast Inference Models (GPT-5-mini, Claude Haiku 4.5, Gemini-2.5 Flash):

• Sub-second response times

• Optimized for throughput and cost

• Excel at pattern recognition and straightforward tasks

• Cost: $0.15–$2.50 per million input tokens

Reasoning Models (OpenAI 5 Pro, Claude Sonnet/Opus 4.5, Gemini 3 Pro):

• 5-30 second response times (sometimes minutes for complex tasks)

• Use chain-of-thought reasoning before answering

• Break problems into logical steps and self-correct

• Cost: $15–$120 per million I/O tokens

On paper, fast inference wins every time. 10x cheaper, 10x faster—obvious choice, right?

Wrong.

When “Slow” AI Ships Faster: The Real Numbers

Fast inference models:

• Save developers 3.6 hours per week on average

• But require significant error correction time

• Quality improvements remain “mixed” across implementations

Reasoning models:

• Save senior engineers up to 4.4 hours per week

• Reduced error rates by 40-75% in complex tasks

• Onboarding time cut nearly in half

Microsoft’s data shows reasoning models now generate accurate code in domains where fast models require 3-5 revision cycles. The “slower” model shipped faster because it got it right the first time.

At my startup, we validated this ourselves: Claude 4.5 (Cursor, Thinking, Max Mode) costs us 10x more per request than GPT-5.1-Codex-mini and 4.5x more per request than Haiku-4.5. But it eliminates the back-and-forth that was eating 6-8 hours per week in debugging and refinement.

Total cost of ownership? Lower with reasoning models. Time to production? Faster.

The Framework: 3 Questions That Reveal Your Path

After analyzing production implementations across financial services, healthcare, and our own stealth build, here’s the decision framework that actually works:

Question 1: What’s Your Error Budget?

Use Fast Inference if:

• Errors are acceptable or easily recoverable

• You have human review already built in

• Mistakes don’t cascade or compound

• Example: Content recommendations, draft generation, brainstorming

Use Reasoning Models if:

• Errors have regulatory, financial, or safety consequences

• Manual correction costs exceed compute costs

• Mistakes create downstream technical debt

• Example: Financial compliance, medical diagnostics, code review for production systems, legal document analysis

Question 2: Is This Multi-Step Logic or Pattern Matching?

Use Fast Inference if:

• Task is single-step or straightforward classification

• Historical patterns strongly predict outcomes

• Speed/throughput is the primary KPI

• Example: Image classification, sentiment analysis, simple Q&A, data extraction

Use Reasoning Models if:

• Task requires breaking down a problem into logical steps

• Context and nuance change the answer significantly

• You need explainable decisions (for compliance or debugging)

• Example: Complex code refactoring, multi-constraint optimization, debugging distributed systems, strategic planning

Question 3: What’s the Correction Loop Cost?

Use Fast Inference if:

• Correction is automated or cheap

• High volume justifies some failures

• Output is intermediate, not final

• Example: First-pass code suggestions, search result ranking, A/B test generation

Use Reasoning Models if:

• Human review is expensive (engineering time, specialist time)

• Each error triggers manual investigation

• Failures block deployment or require rollback

• Example: Database migration scripts, infrastructure-as-code, security patches, customer-facing automation

The Hybrid Architecture Pattern

The teams shipping fastest in November 2025 aren’t choosing one or the other. They’re architecting hybrid systems:

Layer 1 (Fast Inference):

• Initial screening and routing

• High-volume, low-risk decisions

• User-facing responsiveness

Layer 2 (Reasoning Models):

• Complex cases escalated from Layer 1

• Final validation before critical actions

• Tasks where explanation is required

The Implementation Checklist

Before you choose, measure these in your specific context:

For Fast Inference:

1. Run 100 production-like test cases

2. Measure: accuracy, edge case handling, consistency

3. Calculate: error correction time × error rate

4. If (correction cost) < (reasoning premium), use fast inference

For Reasoning Models:

1. Test on your 10 hardest production cases

2. Measure: first-pass accuracy, explanation quality, self-correction

3. Calculate: (avoided errors × correction cost) - (reasoning premium)

4. If positive, reasoning justifies the cost

Hybrid System Design:

1. Categorize your workflows by complexity and stakes

2. Route simple/low-risk → fast inference

3. Route complex/high-risk → reasoning models

4. Monitor and adjust routing rules based on real accuracy data

The pattern is clear: Fast inference for volume, reasoning for value.

The Counterintuitive Truth

At Microsoft, we learned that scale isn’t about doing more faster—it’s about doing the right things reliably. The same lesson applies to AI model selection.

Slow reasoning models often ship faster than fast inference models. Not in spite of being slower, but because they eliminate the iteration tax.

Your $50K decision isn’t really about reasoning vs. speed. It’s about understanding what “fast” actually means in production.

Sometimes, the fastest path to done is taking a few extra seconds to think.

Building with reasoning models in production? Hit reply and tell me—what’s the hardest part of the speed vs. accuracy trade-off in your domain? I read and respond to every reply.

If this framework helped you think differently about your AI architecture, forward it to your tech lead. They’re probably making this decision right now.

– Ishmeet.

I’m documenting my journey building agentic systems in stealth. Connect with me on LinkedIn for real-time updates and lessons learned.

The most powerful AI systems aren’t using the biggest models.

They’re using the right combination of models.

While everyone’s debating GPT-5 vs. Claude 4, production teams at Databricks, Google, and OpenAI have quietly moved to compound AI systems—architectures that orchestrate multiple specialized models instead of relying on one monolithic giant.

The results? 60% cost reduction. Faster iteration. Better outputs.

And most engineers are still building the old way.

The Monolithic Model Myth

For the past three years, the industry sold us a simple story: bigger models solve harder problems.

Need better outputs? Use GPT-4 instead of GPT-3.5.

Still not good enough? Wait for GPT-5.

Want to beat that? Fine-tune an even larger model.

This made sense in 2022. It’s actively costing you money and velocity in 2025.

Here’s why: Single large models are generalists trying to be specialists. They’re expensive to run, slow to iterate on, and optimized for breadth—not depth.

When you route every task through GPT-5 (whether it’s classifying a support ticket or writing a technical spec), you’re paying sports car prices for grocery runs.

What Compound AI Systems Actually Are

A compound AI system breaks complex tasks into components, each handled by the model (or tool) best suited for that specific job.

Instead of one model doing everything:

• A retrieval model finds relevant context from your knowledge base

• A reasoning model (like GPT-4) plans the approach

• A specialized small model handles domain-specific tasks

• A verification model checks output quality

• Traditional code and APIs fill the gaps

Think of it like building software: you don’t write everything in one massive function. You compose smaller, focused modules.

Same principle. Different abstraction layer.

Why This Matters Now

Three years ago at Microsoft, if we wanted to add a feature to a product used by 300 million people, we’d spin up a dedicated team, allocate serious infrastructure, and plan a multi-quarter rollout.

Today, small teams using compound AI systems are shipping comparable functionality in weeks.

The difference isn’t smarter people or better models. It’s better architecture.

The Production Data

Companies using compound AI systems in 2025 are reporting:

Cost efficiency: 40-60% reduction in inference costs by routing simple tasks to smaller, cheaper models and reserving GPT-5/Claude for complex reasoning.

Faster iteration: When you need to improve accuracy on a specific task (say, extracting structured data from invoices), you can swap or fine-tune just that component instead of retraining your entire system.

Better outputs: Specialized models optimized for narrow tasks consistently outperform generalist models on those same tasks—often dramatically.

Easier debugging: When something breaks, you can isolate which component failed instead of debugging a black-box monolith.

Real-World Architecture Example

Let’s say you’re building an AI system to handle customer support tickets.

The monolithic approach (2022-2024):

• Route every ticket → GPT-4

• Let it classify, respond, and escalate

• Cost: $0.03+ per ticket, 3-8 seconds latency

• When it fails, you tune prompts and pray

The compound approach (2025):

1. Fast classifier (small fine-tuned model): Categorizes ticket type in 100ms, costs $0.0001

2. Decision router: Based on category, routes to appropriate handler

• Simple FAQs → Template responses (no LLM needed)

• Standard issues → Specialized 7B model fine-tuned on your docs ($0.001 per response)

• Complex issues → GPT-5 with retrieved context ($0.03 per response)

3. Verification layer: Checks sentiment and completeness before sending

4. Escalation system: Routes edge cases to humans with full context

Result: Average cost drops from $0.03 to $0.005 per ticket. Response quality improves because each component does what it’s optimized for.

That’s an 83% cost reduction while improving output.

When Compound Beats Monolithic: The 3-Question Framework

Not every AI system needs this complexity. Here’s how to decide:

Question 1: Do you have distinct task types with different complexity levels?

• YES → Compound (route based on complexity)

• NO → Monolithic might be fine

Example: Customer support has simple FAQs and complex technical issues. Compound wins.

Question 2: Are costs or latency constraints forcing trade-offs?

• YES → Compound (optimize cost/speed per task)

• NO → Monolithic is simpler to start

Example: You’re processing 100K+ requests daily. Every millisecond and cent matters. Compound wins.

Question 3: Do you need specialized domain knowledge in specific areas?

• YES → Compound (fine-tune specialists)

• NO → Monolithic generalist works

Example: You need medical coding accuracy for healthcare records AND natural conversation for intake. Different models excel at each. Compound wins.

If you answered YES to 2+ questions, you should be building compound.

The Orchestration Layer: Where the Magic Happens

The hard part isn’t picking models—it’s orchestrating them.

You need:

• Routing logic that decides which model(s) to use based on input characteristics

• State management to pass context between components

• Fallback strategies when a component fails

• Monitoring to track performance at the component level

• Version control for each component independently

This is where frameworks like LangGraph, CrewAI, and Microsoft Semantic Kernel come in. They handle the plumbing so you can focus on the architecture.

At my first startup, we scaled to $500K with 15 engineers. Today, you could hit that with 2 engineers using compound AI systems. But only if you architect correctly.

The Hard Truth About Complexity

Compound AI systems are more complex than calling one API.

You’re trading simplicity for:

• Control over cost structure

• Flexibility to iterate components

• Better performance on specialized tasks

• Lower vendor lock-in

This is the same trade-off we make everywhere in software: monolith vs. microservices, single database vs. specialized datastores.

The question isn’t whether compound is “better.” It’s whether the benefits justify the complexity for your specific use case.

For prototypes and MVPs? Start simple. One model. Get to market.

For production systems at scale? Compound is increasingly becoming the only economically viable path.

What This Means for Your Career

The engineers winning in 2025 aren’t the ones who know every model’s capabilities.

They’re the ones who know how to compose systems.

This requires thinking like a systems architect, not a prompt engineer:

• Understanding latency budgets and cost structures

• Designing robust error handling and fallbacks

• Monitoring and optimizing pipelines, not just prompts

• Making build-vs-buy decisions at the component level

If you’ve built distributed systems, microservices, or data pipelines, you already have 80% of the skills needed. AI models are just another type of component.

The reality check:

In 2025, building production AI is less about waiting for better models and more about architecting better systems.

The teams shipping fastest and most cost-effectively aren’t using secret models. They’re using compound architectures that compose the models everyone has access to.

Single models will keep getting better. But compound systems will keep getting cheaper and faster to iterate.

The question isn’t whether to make this shift. It’s whether you’ll make it before your competitors do.

I want to hear from you: Are you currently using compound AI systems in production? What’s been your biggest challenge? Hit reply and let me know—I read every response.

And if this clicked for you, forward it to your technical co-founder or engineering lead. They’re probably still paying GPT-5 prices for everything.

— Ishmeet

P.S. Building something with compound AI? I’m documenting my journey building agentic systems in stealth. Connect with me on LinkedIn for real-time updates and lessons learned.

OpenAI launched AgentKit. Microsoft dropped their unified Agent Framework two days earlier. Meanwhile, LangGraph, CrewAI, and a dozen other orchestration frameworks are fighting for mindshare with engineers who just want to ship.

Here’s what nobody’s saying: The orchestration framework you choose in the next 30 days will matter more than which model you use.

I learned this the hard way building Agentic systems for scale. The infrastructure decisions you make early—when everything feels like it’s “just working”—determine whether you’re debugging spaghetti code at 2 AM or confidently shipping features.

Let me show you what’s actually happening and how to think about this decision.

The Framework Explosion Nobody Warned You About

Four weeks ago, I counted 12 major AI agent frameworks. Today? That number is closer to 20.

OpenAI AgentKit:

• Modular toolkit for building, deploying, and optimizing agents

• Tight integration with OpenAI’s models (obviously)

• Focus: Developer experience and deployment simplicity

• Still early—documentation is thin, but early adopters report fast setup

Microsoft Agent Framework:

• Unified AutoGen + Semantic Kernel into one production-ready SDK

• Built for enterprise: observability, durability, compliance out of the box

• Azure AI Foundry integration means it’s battle-tested at KPMG-level scale

• Multi-agent orchestration with “Magentic One” patterns

• API integration via OpenAPI and Model Context Protocol (MCP)

LangGraph/LangChain:

• The community favourite for stateful, graph-based workflows

• Massive ecosystem advantage—if someone built it, there’s a LangChain integration

• Learning curve is real, but so is the flexibility

CrewAI:

• Specialized for collaborative multi-agent teams

• Recent updates added observability and Slack/Teams integrations

• Great for orchestrating “agent squads” tackling complex problems

OpenAI Swarm:

• OpenAI’s experimental framework for lightweight agent handoffs

• Stateless, explicit, debuggable

• Not production-ready, but shows where OpenAI’s thinking long-term

Why does this matter? Because 42% of AI projects show zero ROI, and the #1 reason is poor integration architecture.

What I Learned Building Agents at Scale (That Applies Here)

At my startup, we deployed hundreds of Agents at once across web for multiple use cases. We learned three brutal lessons:

1. The demo is 20% of the work. Production is the other 80%.

Every framework shows you the same demo: “Look, my agent answered a question!” Cool. Now show me:

• How you handle failures when the LLM times out

• What happens when agents disagree

• How you debug a 12-step workflow that failed on step 9

• How you version control your agent logic

Answer: Observability, tracing, real-time monitoring, alerting.

2. Your first architectural decision becomes your ceiling.

When we built our distributed system, we made a choice about our message queue early on. It worked great for 50 customers. At 200? We hit the wall and spent months rewriting core infrastructure.

Pick a framework that’s too simple (like basic prompt chaining), and you’ll rewrite everything when you need stateful workflows. Pick something too complex (looking at you, over-engineered agent meshes), and you’ll spend more time maintaining the framework than building features.

3. Integration is everything.

You’re not building agents in isolation. You need them to:

• Pull data from your CRM

• Trigger workflows in your project management tool

• Write to your database

• Play nice with your existing auth system

This is where you think about MCP, A2A, Prompt Injection etc. Personally, I feel LangGraph wins here. You can either use community nodes or inject your own custom code.

Becoming Agentic

The Agentic Mindset Shift: Thinking in Goals, Not Code

To prepare for my upcoming trip to Japan, I asked ChatGPT about the weather in Tokyo. When I repeated the same question in a new chat, I got two different responses. The facts were the same, but the style and framing shifted…

Read more

7 months ago · 5 likes · Ishmeet Sethi

The Decision Framework (From Someone Who’s Made This Mistake)

Here’s how to pick your agent orchestration framework based on where you are:

If you’re a solo founder or early-stage startup:

→ Use LangChain/LangGraph

• Massive community means you won’t get stuck

• Flexibility to pivot as your product evolves

• Free, open-source, works with any model

• Trade-off: Steeper learning curve, more setup

If you’re building for enterprise or need compliance:

→ Use Microsoft Agent Framework

• Observability and governance are table stakes

• Azure integration if you’re already in that ecosystem

• KPMG and other enterprises are already using it in production

• Trade-off: Heavier, more complex, tied to Azure

If you’re all-in on OpenAI:

→ Watch AgentKit closely, but wait 60 days

• It’s too new—docs are sparse, patterns aren’t established

• But if you’re already deep in the OpenAI ecosystem, it might be your fastest path in Q1 2026

• Trade-off: Betting on an unproven framework

If you want simple, collaborative agent teams:

→ Try CrewAI

• Purpose-built for multi-agent collaboration

• Good for well-defined workflows with clear agent roles

• Trade-off: Less flexible for complex state management

If you’re experimenting/learning:

→ Start with OpenAI Swarm

• Lightweight, explicit, easy to understand

• Great for learning agent coordination patterns

• Trade-off: Experimental—not production-ready

What Actually Matters: The Three Tests

Forget the marketing. Here’s how to evaluate any framework:

Test 1: The Failure Test

Build an agent that calls an external API that fails 50% of the time. Can you:

• Retry with exponential backoff?

• Route to a different agent?

• Log exactly what happened for debugging?

If the framework makes this hard, run.

Test 2: The Handoff Test

Build three agents: one for intake, one for processing, one for output. Make them pass context between each other. Now change the middle one’s logic. Did you have to rewrite everything?

Good frameworks (Microsoft, Swarm, LangGraph) make handoffs explicit and maintainable. Bad ones create spaghetti dependencies.

Test 3: The Production Test

You deployed your agent. Now:

• Can you see what it’s doing in real-time?

• Can you roll back a broken version?

• Can you A/B test different agent configurations?

• Can you track costs per agent execution?

If the answer is “I could build that,” you’ve chosen wrong. You’ll spend months building observability instead of features.

What I’m Watching (And Building With)

For prototyping: n8n.io → no code, easy to test the concepts.

For production: LangGraph. The flexibility is unmatched when I’m still figuring out the workflow.

For learning: I cloned Swarm and built a few test agents. Understanding OpenAI’s mental model for agent coordination is valuable, even if I don’t use it in production.

What You Can Do This Week

Don’t pick a framework based on Twitter hype or slick demos. Here’s your action plan:

Day 1-2: Define your constraints

• Are you building for enterprise or startup speed?

• Do you need multi-model support or are you all-in on a single LLM → GPT, Anthropic, Gemini?

• What’s your team’s existing infrastructure? (Azure? AWS? Bare metal? I don’t care?)

• What’s your failure tolerance? (Prototype vs. production)

Day 3: Run the Three Tests

• Pick 2-3 frameworks that match your constraints

• Build the same simple multi-agent workflow in each

• Break things deliberately and see how hard debugging is

• Time yourself—complexity reveals itself in implementation time

Day 4-5: Build the ugly version

• Pick the framework that passed the tests

• Build your actual use case, not a demo

• Integrate with one real system (your CRM, database, etc.)

• If it feels painful now, it’ll be worse at scale

Resources & References:

• Microsoft Agent Framework docs: Azure AI Foundry

• OpenAI AgentKit announcement: OpenAI Blog

• LangGraph tutorials: Start with the official docs—skip the Medium posts

• Swarm repo: github.com/openai/swarm (for learning patterns)

Budget: 20 hours max.

If you can’t validate a framework in 20 hours, it’s too complex for your current needs.

The Bottom Line

The AI framework wars are here. But unlike the model wars (where GPT-5 and Claude 4 are mostly interchangeable for 90% of tasks), your AI orchestration framework choice has compound effects.

Pick wrong, and you’ll be rewriting your agent stack in Q3 when you should be shipping features. Pick right, and you’ll be the team that ships while everyone else is stuck in prototype hell.

I’ve lived through the “we’ll just rebuild it later” decision. At startup scale, “later” came at month 18 and cost us 6 months of velocity.

The agents aren’t the hard part. The orchestration is.

One question for you: What’s stopping you from shipping your first agent to production? Is it the framework choice, the integration complexity, or something else?

Hit reply and tell me. I read every response, and your answer might shape the next deep dive.

If this helped you think through the framework maze, forward it to your technical co-founder or that engineer on your team who’s been researching agents for the past month.

—Ishmeet

P.S. — I’m building in stealth with agentic AI right now. The lessons I’m learning about what actually works (vs. what demos well) are going straight into this newsletter & LinkedIn. If you want the unfiltered, battle-tested insights as I ship this thing, you’re in the right place.

He’s not alone. 53% of senior developers now believe LLMs code better than most humans. That’s not junior developers uncertain about their skills. That’s veterans with 10+ years of experience questioning their entire identity.

I get it. I spent 10 years becoming a better engineer. At Microsoft, I optimized systems affecting hundreds of millions of users. I prided myself on writing elegant, efficient code. My identity was wrapped up in my craft.

Then I started building with AI agents full-time. And I had to face an uncomfortable truth: The game changed. And I was still playing by the old rules.

Here’s what nobody’s saying out loud: The crisis isn’t that AI is getting better at coding. It’s that we built our entire professional identity on being “the person who writes code”—and that role is evaporating faster than we can adapt.

But here’s the plot twist: The engineers thriving right now aren’t the ones fighting this change. They’re the ones who figured out what actually matters when AI can already code.

The Uncomfortable Data

Let’s start with reality, not wishful thinking.

Adoption is universal. 84-90% of developers use AI coding tools. 51% use them daily. This isn’t coming—it’s here. GitHub Copilot has 360,000 paying customers and 90% penetration in Fortune 100 companies. Cursor crossed $500M ARR.

These numbers don’t lie: AI pair programming is now table stakes, not competitive advantage.

But here’s where it gets interesting. Recent studies show nuanced results:

- 80% of developers report productivity gains when using AI tools

- 62% of engineering teams see 25%+ productivity boosts

- But a rigorous MIT study found experienced developers were 19% SLOWER when using cutting-edge AI tools

How do we reconcile this?

The answer reveals everything about the identity crisis we’re facing.

The Real Problem: We’re Measuring the Wrong Thing

When that senior engineer told me Claude writes cleaner code, he was right. Recent benchmarks confirm it: Fine-tuned AI models generate code with fewer high-severity bugs and better maintainability metrics than average human developers.

But that comparison— “AI vs. human code quality” —is the wrong frame entirely.

At my startup, we scaled to $500k revenue with 15 people, competing against teams of 100+. We didn’t win because we were better coders. We won because we understood what to build, for whom, and why.

Coding was the implementation layer. The value was in everything else.

Yet somehow, over the past decade, the industry convinced us that “great engineer = great coder.” We optimized for syntax, speed, and elegance. We built entire identities around clean code and clever algorithms.

Now AI can match or exceed that—and we’re left wondering: If I’m not the one writing the code, what am I?

Wrong question.

The right question: What actually creates value in software development?

What AI Can’t Do (Yet)

I’ve been building agentic AI systems daily for months. I’ve watched Claude generate entire features, write tests, refactor codebases. It’s genuinely impressive.

But here’s what I’ve learned from actually shipping with AI:

1. AI doesn’t know what to build.

Give Claude a perfectly specified task, and it’ll execute brilliantly. But it can’t look at your business, understand your users, identify the problem that actually needs solving, and decide what to build next.

That requires judgment. Intuition. Experience. Understanding human behavior and business context.

At Microsoft, the hardest part of shipping features to hundreds of millions of users wasn’t writing the code. It was understanding the trade-offs: performance vs. features, simplicity vs. power, user needs vs. technical constraints.

AI tools excel at “how.” They’re lost at “what” and “why.”

2. AI doesn’t understand your system.

AI can write beautiful code in isolation. But real software engineering is about systems: how components interact, where technical debt lives, what’s brittle and what’s flexible, which abstractions will hold and which will break.

When building automation systems for Unilever and Whirlpool, our edge wasn’t writing the prettiest code. It was understanding how our system integrated with 15 other systems, where the failure points were, and how to design for reliability at scale.

AI sees code. Experienced engineers see architecture.

3. AI doesn’t handle novel problems.

AI is spectacular with patterns it’s seen before. Feed it common use cases, and it’ll outperform most developers.

But when you hit genuinely novel problems—weird edge cases, unusual performance bottlenecks, integration challenges nobody’s blogged about—AI flounders.

That’s when you need an engineer who can reason from first principles, debug without Stack Overflow, and solve problems that don’t have documented solutions.

4. AI doesn’t know when it’s wrong.

Here’s the killer: AI generates code confidently, even when it’s subtly broken. It doesn’t understand the business logic, so it can’t catch logical errors. It doesn’t know your architecture, so it can’t spot integration issues.

You need someone who can read the code, understand what it’s supposed to do, spot the mismatch, and fix it. Someone with enough experience to know when “working code” isn’t actually correct.

Senior developers are 2.5x more likely to ship AI-generated code to production than juniors. Not because they’re better at prompting. Because they’re better at validating, correcting, and integrating what AI produces.

The Identity Shift: From Coder to Orchestrator

Here’s the shift that’s actually happening:

Old Identity: I am the person who writes the code.

New Identity: I am the person who knows what code should exist, why, and whether it’s right.

This isn’t a demotion. It’s an elevation.

Think about it: When I was at Microsoft, the most valuable engineers weren’t the ones who could write the fastest sorting algorithm. They were the ones who could look at a feature request, understand the user need behind it, design the right abstraction, identify the failure modes, and guide the team to ship something reliable.

Coding was part of that. But it wasn’t the core value.

Now AI handles much of the implementation. What’s left?

Everything that actually matters:

- Understanding what problems are worth solving

- Designing systems that won’t collapse under edge cases

- Making architectural decisions that compound over time

- Integrating components across complex systems

- Debugging issues AI can’t see

- Validating that solutions actually work in production

- Communicating technical decisions to non-technical stakeholders

- Mentoring others to think systematically

These skills have always been what separated good engineers from great ones. AI didn’t change that. It just made it obvious.

The New Skills That Matter

If you’re feeling the identity crisis, here’s what to focus on:

1. Learn to Orchestrate AI, Not Compete With It

Stop trying to out-code AI. You won’t win, and it’s the wrong competition.

Instead, get fluent in directing AI tools:

- Which tool for which task (Cursor for refactoring, Claude for architecture, Copilot for autocomplete)

- How to specify context so AI generates correct, not just plausible, code

- When to trust AI output and when to rewrite from scratch

- How to review AI-generated code for subtle bugs

Treat AI like a junior engineer: talented, fast, but needs oversight.

2. Go Deeper on System Design and Architecture

AI can implement. It can’t architect.

Double down on:

- Understanding distributed systems, concurrency, and state management

- Designing APIs that won’t break when requirements change

- Making trade-offs between performance, maintainability, and complexity

- Anticipating failure modes before they happen

These skills compound over decades. AI won’t touch them anytime soon.

3. Strengthen Your “Why” Muscles

The hardest part of building my startup wasn’t coding. It was figuring out what to build that customers would actually pay for.

AI can’t do product thinking. It can’t talk to users, understand pain points, prioritize features, or make strategic bets.

Get closer to the business:

- Understand your users deeply

- Learn to identify problems worth solving

- Get comfortable with ambiguity and trade-offs

- Develop judgment about what ships and what doesn’t

Engineers who can do this become indispensable.

4. Build Communication and Leadership Skills

Here’s a truth that hurts: If AI can automate your entire job, you weren’t adding enough strategic value.

The engineers who thrive in the AI era are the ones who can:

- Explain technical decisions to non-technical stakeholders

- Lead teams through ambiguous problems

- Mentor others to think systematically

- Influence product and business strategy

These “soft” skills are now the hard differentiators.

At Microsoft, the engineers who got promoted weren’t the best coders. They were the ones who could drive alignment across teams, communicate effectively, and lead through complexity.

That’s always been true. AI just made it undeniable.

What This Means for Your Career

If you’re early in your career, this feels terrifying. The traditional “learn to code → get better at coding → become senior engineer” path is breaking.

Here’s what I’d focus on if I were starting today:

Year 1-2: Build the fundamentals, but with AI.

Don’t avoid AI tools. Use them, but force yourself to understand what they’re doing. Review every line. Debug failures manually. Build intuition about what’s correct vs. what just looks correct.

You’re not learning to code. You’re learning to think like a system.

Year 3-5: Go deep on architecture and domain expertise.

Pick a domain (fintech, healthcare, infrastructure, AI systems) and become an expert. Understand the business problems, regulatory constraints, and unique challenges.

Generalist “I write code” engineers are becoming commoditized. Specialists who deeply understand a problem space are becoming more valuable.

Year 5+: Build leadership and strategic thinking.

Shift from “Can I build this?” to “Should we build this? What’s the right approach? What are the trade-offs?”

Become the person who defines what gets built, not just the person who builds it.

If you’re a senior engineer feeling lost, here’s the reframe:

You spent 10 years building skills AI is now automating. That’s not wasted—those skills are the foundation for what comes next.

You know what good code looks like, so you can evaluate AI output. You’ve debugged enough systems to spot subtle issues AI misses. You’ve shipped enough features to know the difference between “works in demo” and “works in production.”

Those experiences don’t disappear. They become your quality filter for an AI-accelerated world.

The question isn’t “What do I do if AI codes better than me?”

It’s “How do I use my 10 years of experience to direct AI toward building the right thing, the right way?”

That’s the skill. That’s the identity.

The Real Competitive Advantage

Here’s what I’ve learned building at scale, both at Microsoft and my startup:

Fast iteration beats perfect code. Always has. AI makes iteration faster. Engineers who embrace this ship more, learn faster, and compound their advantage.

System thinking beats implementation skill. The best engineers I worked with weren’t the fastest coders. They were the ones who could see three moves ahead—understanding how decisions today create problems (or opportunities) six months from now.

Judgment beats knowledge. You can Google syntax. You can ask AI for implementation. But knowing which solution to pick, when to take on technical debt, and what trade-offs matter—that’s unteachable. And irreplaceable.

The engineers who get this are thriving. They’re not fighting AI. They’re leveraging it to spend more time on the parts that actually create value.

They’re shipping faster, thinking bigger, and building things that would’ve taken teams of 20 just two years ago.

Meanwhile, the engineers clinging to “I am the person who writes the best code” are watching their identity—and their career—erode.

Your Next Move

This week, do this exercise:

1. List the last 3 significant technical decisions you made.

Not implementation details. Decisions. What to build. How to architect it. Which trade-offs to make.

2. Ask yourself: Could AI have made these decisions?

Be honest. If AI could’ve made the same call with the same context, that’s a sign you’re operating too close to implementation.

3. Identify one strategic skill to develop.

Pick ONE:

- System design and architecture patterns

- Domain expertise in your industry

- Product thinking and user research

- Technical communication and leadership

- AI orchestration and tool mastery

Commit to one focused learning project this month. Not a tutorial. Not a course. Build something that stretches that skill.

Time estimate: 2 hours for reflection, 10-20 hours for the skill-building project.

Difficulty: Uncomfortable (you’re leaving your comfort zone), but clarifying.

The engineers who win in the AI era aren’t the ones with the best coding skills. They’re the ones who figured out what matters beyond coding.

That’s the identity shift. That’s the opportunity.

Where are you in this transition? Hit reply and tell me—are you fighting the change, embracing it, or somewhere in between? I read every response, and your perspective might shape what I explore next.

If this resonated, forward it to another engineer navigating this shift. We’re all figuring this out in real-time, and the honest conversations matter more than the polished takes.

—Ishmeet

P.S. — I’m documenting the real-time lessons from building agentic AI systems on LinkedIn. No theory. No hype. Just what’s actually working (and breaking) when you build with AI every day. Follow along if you want the unfiltered version.

They launched Apps inside ChatGPT — not just GPTs, but real, branded integrations from companies like Canva, Spotify, Coursera, and Zapier.

It looks like an App Store.

But underneath, it’s something much bigger.

1. The Shift: From GPTs to Apps

When OpenAI launched the “GPT Store” earlier this year, it didn’t take off.

Most GPTs were niche, fragmented, and poorly discoverable.

The new model fixes that by changing context, not just design:

• Apps now live inside the chat.

• You can talk to them like you talk to ChatGPT.

• ChatGPT itself decides when to invoke them.

That last point is key — ChatGPT is now the orchestrator.

It decides when an app is relevant, passes context to it, and blends the response back into your conversation.

This isn’t a plugin marketplace.

It’s an agentic runtime environment.

2. Apps as Economic Units

Until now, most GenAI apps have been built on top of OpenAI —

powered by its API but existing outside its ecosystem.

This new model reverses that relationship.

Now, you can build within ChatGPT.

And for the first time, developers will be able to monetize directly inside the product.

Think about what that means:

• Distribution is no longer about traffic or virality — it’s about intent.

• You don’t fight for visibility in app stores or ad feeds — you surface when the conversation demands you.

• Monetization happens where cognition happens — inside the chat loop itself.

This is a completely different kind of platform economics.

Instead of App Store SEO, you’ll optimize for agent reasoning.

Instead of ad funnels, you’ll design for goal completion.

3. A New Layer of Distribution

In the Web era, distribution was driven by links.

In the Mobile era, it was icons.

In the Agentic era, it’s intent.

You no longer “open” apps. You invoke them.

“Find me a house” → Zillow.

“Make a logo” → Canva.

“Summarize this contract” → Notion.

ChatGPT becomes the layer that understands what you’re trying to do and routes your goal to the best agent or app for it.

That’s a massive architectural shift.

It’s not about replacing mobile or web apps — it’s about redefining entry points.

For developers, this means your app is no longer a destination.

It’s a capability within a reasoning system.

4. The App Store Becomes an Economy

The real story here isn’t UI polish.

It’s the creation of an internal marketplace for agentic value.

OpenAI is effectively building an agent economy:

• Users express goals.

• ChatGPT reasons which app can fulfill them.

• Apps transact and deliver outcomes.

And for the first time, there’s a closed payment loop —

which means OpenAI owns both sides of the monetization stack:

the discovery layer (ChatGPT) and the transaction layer (App payments).

In other words, this is Apple’s App Store moment — but for AI agents.

5. What This Means for Builders

If you’re building in the GenAI space, this announcement changes your strategy:

• Design for orchestration, not ownership.

  Your app’s success will depend on how well agents can call you.

• Optimize for intent matching.

  Visibility now depends on reasoning alignment, not keyword ranking.

• Think in services, not interfaces.

  Your UI may disappear. What remains is your function — the problem you solve.

The Agentic Web won’t be a place users browse.

It’ll be a space where systems delegate.

6. The Bigger Picture

This move makes ChatGPT not just an AI assistant — but a computational marketplace.

Every conversation becomes a surface for value exchange.

It’s not the end of the App Store era.

It’s the beginning of its reincarnation —

one where conversation replaces clicks,

and reasoning replaces ranking.

The question for developers is no longer:

“How do I get users to download my app?”

It’s:

“How do I get agents to choose me?”

That’s the future of agentic monetization — and OpenAI just built the first version of it.

The App Store changed software once by distributing apps. OpenAI’s ChatGPT Apps will change it again — by distributing agency.

About This Newsletter

Here, I’ll share insights on how engineers, startup builders, and technical leaders can make the transition into an agentic world—where software doesn’t just respond, it acts.

Ready to take the first step toward becoming agentic? Let’s connect and design a plan that fits your journey.

Note: For feedback, please respond to this email directly or connect with me using my Calendly link above.

A true agentic system, by contrast, introduces autonomy, adaptability, and goal-driven intelligence. This unlocks benefits beyond just “making workflows faster.”

Here are the key ways agentic systems go beyond workflows:

🔑 1. Adaptability in Uncertainty

• Workflow: Runs step A → B → C. If B fails, everything halts.

• Agentic System: Detects failure at B, reasons about alternatives, retries, or reroutes to reach the end goal.

➡️ Benefit: Resilience in dynamic, real-world conditions where tasks rarely follow a neat script.

🔑 2. Contextual Reasoning & Reflection

• Workflow: Follows static rules, regardless of shifting inputs.

• Agentic System: Can reflect (“did this step work?”), revise plans, and learn from previous runs.

➡️ Benefit: Continuous improvement and reduced human babysitting.

🔑 3. Cross-Domain Orchestration

• Workflow: Usually confined to one domain or toolset.

• Agentic System: Uses multiple tools/APIs, decides when to invoke which, and integrates across domains.

➡️ Benefit: Complex problem-solving that spans marketing, finance, engineering, or research without requiring pre-programmed paths.

🔑 4. Personalization & Memory

• Workflow: Treats every user the same.

• Agentic System: Maintains long-term memory and adapts to user history, preferences, and evolving needs.

➡️ Benefit: Hyper-personalized experiences (fitness coaching, tutoring, customer service).

🔑 5. Exploration & Initiative

• Workflow: Executes only what’s encoded.

• Agentic System: Can take initiative, explore options, and even propose new goals (within guardrails).

➡️ Benefit: Discovery of solutions humans didn’t explicitly program—like suggesting new business opportunities or diagnosing unseen risks.

🔑 6. Strategic Leverage

• Workflow: Saves time.

• Agentic System: Unlocks strategic advantage—by freeing teams from micro-management, surfacing insights, and autonomously pursuing objectives.

➡️ Benefit: Humans can focus on vision, strategy, and judgment, while agents handle operational complexity.

Workflows make processes faster; agents make them smarter, adaptive, and resilient. That leap is what justifies calling something “agentic” instead of just “automated.”

Not a big deal in casual conversation. But this kind of indeterminism is exactly what makes building AI Agents so challenging.

Coming from a decade of software engineering, I had to unlearn old instincts. Traditional systems are predictable and rule-bound: same input, same output. As a developer, you control the execution path and the type of output—string, integer, float, or object.

With LLMs and Agents, that model breaks down. Same input, same model, different outputs. Context, randomness, and adaptive reasoning all shape the response. The system explores multiple possible paths instead of just one.

This article will help you reframe the mental model to adapt towards Agentic Engineering. Think in Goals, Not Code.

Deterministic vs. Indeterministic Thinking

Deterministic systems are predictable, rule-bound and provide fixed outputs for the same input. Indeterministic or Probabilistic systems explore multiple possible paths, influenced by context, randomness, or adaptive reasoning.

For agents to work in our favour, there should be a balance of both. In my previous article, I talked about how the autonomy is an important trait for Agents. Indeterminism gives this autonomy to agents so they can explore multiple possible paths given the context and environment. However, they should still convert on useful outcomes.

Agents need autonomy to plan/execute actions toward goals.
- OpenAI

Becoming Agentic

Agent Washing: Why Not All ‘AI Agents’ Are Created Equal

Two weeks ago, Grammarly announced a suite of “AI agents” designed to help with everyday writing tasks—things like finding citations, paraphrasing text, or polishing tone. All of these agents probably add immense value to user workflows. But are they actually Agents? Let’s find out…

Read more

7 months ago · 1 like · Ishmeet Sethi

What is Agency?

In Agentic AI, agency means shifting from “I tell you every step” to “I tell you the destination, you figure out the path.” At its core, agency means the capacity to act autonomously toward goals rather than just execute fixed instructions. In the context of AI:

• Traditional software = scripted determinism. You hard-code every rule and pathway. The system only does what you explicitly tell it.

• Agentic AI = goal-directed autonomy. You specify the goal, and the system reasons, plans, and chooses actions to reach it.

Keeping Agency Safe

The agentic flexibility enables adaption to new information, creativity in problem solving and emergent behaviours like tool-use or collaboration. It is extremely important to keep it in check to avoid the “runaway” behaviour like hallucinations, loops or irrelevant outputs. Debugging becomes harder.

Practical Framework: Combining Both Worlds

• Goal-Oriented Design: Define what success looks like, not every step.

• Scaffolding: Provide deterministic structures (APIs, tools, workflows).

• Exploration: Let agents fill gaps with indeterministic reasoning and exploration.

• Guardrails: Add checkpoints to ensure outcomes are relevant and safe.

The Shift in Thinking

Instead of asking “What steps should the agent follow?”, try asking “What goal do I want, and what guardrails keep it safe?”. Instead of finding the availability to schedule a meeting, design an agent that ensures:

• The meeting is scheduled within your availability (Guardrails)

• With the right people (Goal)

• On the platform of your choice (Scaffolding)

Building agents means relinquishing micro-control. Your job isn’t to script every move but to design environments where agents can act effectively toward goals. This mindset shift is the difference between workflows branded as “agents” and truly agentic systems.

About This Newsletter

Here, I’ll share insights on how engineers, startup builders, and technical leaders can make the transition into an agentic world—where software doesn’t just respond, it acts.

Ready to take the first step toward becoming agentic? Let’s connect and design a plan that fits your journey.

The “Agent” branding today sits at an intersection: somewhere between the strongest wave of marketing momentum and a technological leap that has reshaped how we perceive interfaces and software. True agentic systems exhibit enough agency to reason, plan, and act toward a goal. The last piece—the goal—is the most important.

What is an Agent?

While there are hundreds of definitions for Agents, here are what some of the first movers have to say:

• OpenAI: Agents are systems that independently accomplish tasks on your behalf.

• Anthropic: Agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks

• Langchain: An AI agent is a system that uses an LLM to decide the control flow of an application

• Google: AI agents are software systems that use AI to pursue goals and complete tasks on behalf of users. They show reasoning, planning, and memory and have a level of autonomy to make decisions, learn, and adapt.

While OpenAI’s definition is very generic, Anthropic has taken a more definitive stance including an important trait of autonomy. LangChain, from a technical standpoint, adds clarity on how autonomy manifests—the control flow. On the other hand, Google’s definition feels contradictory: an AI system should not “pursue goals” but rather work toward them. Completing tasks can be interpreted broadly. ChatGPT can search the internet (a task) for a user, but is that truly agentic? Gemini can write code (a task), but does that qualify as agentic?

For the purposes of this article, I’ll stick with the following working definition:

An AI Agent is a system that uses LLM to decide the control flow of an application, leveraging tools and autonomy to accomplish the given goal.

This combines Anthropic’s focus on autonomy with LangChain’s emphasis on control flow—giving us a more complete picture of what Agents really are.

Agentic Traits

Now that we’ve defined an Agent, what traits should it have? Fortunately, there’s broad alignment here:

• Autonomy: Makes decisions (vs follows rules).

• Goal‑driven: Acts toward an objective, potentially through multiple steps or tools.

• Reasoning & Planning: Adapts mid-stream (not linear scripting).

• Tool & Memory-Oriented: Uses APIs, stores context, plans actions.

• Dynamic Control Flow: Chooses next action based on outcomes.

• Guardrails / Safety: Applies checks, fails safely, escalates when needed.

Some Real Agentic Systems

• OpenAI’s ChatGPT Agent: can autonomously handle multi-step real‑world tasks via virtual computer, with safety checks and autonomy

• Microsoft Copilot + Azure SRE Agent: elevated from pair-programmer to peer that autonomously addresses site reliability issues; daily agent usage has more than doubled year‑over‑year

• Coding Agents (Cursor, Windsurf): extend beyond autocomplete by reasoning about intent, making multi-step code edits and refactoring projects.

The Marketing Spin

According to a partner at a16z, some startups wrangle the “AI agent” label to command higher pricing for what are essentially chat interfaces over knowledge bases. When you label routine tasks or prompt-based workflows as “agents” with minimal decision making, you risk diluting its meaning, and potentially its perceived value. It works in favour of the companies so they can demand higher prices while there is a minimal knowledge in the leadership and decision-making roles.

How you can avoid Agent Washing?

For product leaders & technologists:

• Be cautious of over-branding: demand substance, autonomy, planning capabilities.

• Avoid hype traps: Differentiate “agentic” from “branded convenience.”

• Invest real agent design: with orchestration, guardrails, evaluation layers.

• Set expectations: Agents are powerful, but concerns remain—oversight, hallucinations, safety, and liability.

If you’re looking for a more detailed breakdown, I’ve created a free checklist that helps identify whether a system is truly agentic. Click here to download.

Closing Thoughts

Semantic inflation of “AI Agent” is more than marketing fluff—it dilutes meaning and can mislead decision-makers. Whether Grammarly fits the criteria for an agentic system, I’ll leave for you to decide.

True agentic systems offer autonomy, adaptability, and real utility—but require careful architecture and design. Use the insights (and the checklist) to push back against jargon—and to design agents that are genuinely capable.

About This Newsletter

Here, I’ll share insights on how engineers, startup builders, and technical leaders can make the transition into an agentic world—where software doesn’t just respond, it acts.

Ready to take the first step toward becoming agentic? Let’s connect and design a plan that fits your journey.

Five months ago, I left Microsoft and joined a Silicon Valley founder to build Jobreel. I became the first (and only) hire, working directly alongside the founder.

Jobreel wasn’t entirely new to me—I had been consulting with them for a few months before finally deciding to jump ship and ride the startup roller coaster full-time.

And startups weren’t new either. Back in 2017, I built my own, investing $125,000 and giving it four years of my life. (That story deserves its own post someday.)

The Big Pivot

One week in, we decided to pivot. And not just a simple idea tweak—this was a complete overhaul.

We shifted the concept, the technology, and even the industry we were chasing. The new focus? Agentic AI.

I had a decade of experience building iOS apps, from Microsoft Teams to RBC Mobile Banking and several others from the ground up. But AI? Agents? That was uncharted territory for me.

My first thought was:
“I have ZERO idea what Agents are. Heck, I have ZERO idea about AI. How am I going to do this?”

Well, that’s the perks of startups: Learning. A tons of it. That’s the only guarantee you get while building a startup. So I dove straight in.

How I learned AI and started building Agents

1. Went deep into basics

   • What are Agents?

   • What does Agency actually mean?

   • How do LLMs process information?

2. Took structured courses on deeplearning.ai

   • Multi AI Agent Systems with crewAI

   • AI Agents in LangGraph

   • Long-Term Agentic Memory with LangGraph

   • Functions, Tools and Agents with LangChain

3. Learned By Building: I’ve always believed the best way to learn is by building. My first project? A simple agent that could chat and maintain thread memory. From there, I kept stacking my knowledge, one token at a time.

How Will You Become Agentic?

It’s no secret anymore—the future of tech is AI.

For individuals and organizations alike, the smartest move is to adopt AI sooner rather than later. Which brings us to a question worth asking yourself:

👉 How—and when—will you become agentic?

(And yes, as a first step, subscribing to this newsletter is a pretty good start. Pardon the selfish plug. 😅)

Subscribe now

About This Newsletter

This is the very first issue of Becoming Agentic.

Here, I’ll share insights on how engineers, startup builders, and technical leaders can make the transition into an agentic world—where software doesn’t just respond, it acts.

Ready to take the first step toward becoming agentic? Let’s connect and design a plan that fits your journey.