AB's Reflections

Tag: thoughts

  • The AI Stack Is Running on Borrowed Infrastructure — And What Happens When It Isn’t

    The AI Stack Is Running on Borrowed Infrastructure — And What Happens When It Isn’t

    The GPUs running AI workloads today were designed to render video game graphics. The programming languages agents use were built for human readability. The development processes — sprint cycles, code reviews, deployment windows — are all structured around human working hours and attention spans.

    Despite these constraints, AI agents are already building C compilers from scratch for roughly $20,000 in compute costs and consistently outperforming average human engineers on standard tasks. When purpose-built infrastructure arrives, following the same vertical integration pattern we saw transform smartphones, the cost and capability equation changes dramatically. It’s the natural evolution of any technology platform.

    The smartphone parallel: five layers of integration

    Early smartphones ran on repurposed mobile phone hardware with desktop-derived operating systems. They worked, but the architecture was borrowed. Then came the integration layers, each delivering step-change improvements:

    Layer one: Purpose-built mobile operating systems — iOS and Android, optimised for touch interfaces and mobile constraints rather than adapted from desktop paradigms.

    Layer two: Custom silicon designed specifically for mobile workloads. Apple’s A-series chips weren’t just smaller desktop processors; they were architected from the ground up for mobile use cases.

    Layer three: Specialised programming frameworks — Swift and Kotlin — designed for mobile development patterns rather than ported from other contexts.

    Layer four: Cloud-native architectures that assumed mobile-first applications, not desktop apps squeezed onto smaller screens.

    Layer five: An entire ecosystem of services built around mobile devices as the primary platform, from payments to authentication to location services.

    Each layer compounded the improvements of the previous one. The difference between a 2007 iPhone and a 2015 iPhone wasn’t just better specs — it was a fundamentally different platform enabled by vertical integration.

    The AI stack is entering the same progression.

    What purpose-built looks like

    Custom AI chips are already in development. Google’s TPUs, various ASICs, and well-funded startups are working on silicon designed for neural network operations rather than graphics rendering. These aren’t incremental improvements on Nvidia’s architecture — they’re different approaches optimised for different workloads.

    Programming paradigms are shifting from human-oriented languages to frameworks designed for agent workflows. AI agents don’t need readable variable names or structured flow control designed for human comprehension. They work with tokens and can operate on representations optimised for their own processing, not ours.

    Development processes are being redesigned around agent capabilities. Continuous, asynchronous, parallel-by-default workflows rather than sequential sprints bounded by human availability. The infrastructure assumes agents are the primary operators, with humans in supervisory roles.

    Aaron Levie maps the emerging stack: agent-specific sandboxed compute environments (E2B, Daytona, Modal, Cloudflare), agent identity and authentication systems, agent-native file storage and memory, agent wallets for microtransactions (Stripe, Coinbase), and agent-optimised search (Parallel, Exa). These aren’t conceptual products — these companies exist and are building now.

    His framing of “make something agents want” — riffing on Paul Graham’s “make something people want” — captures the shift. Software is being redesigned with agents as the primary user. Every feature needs an API. Every service needs an MCP server. If agents can’t sign up and start using your product autonomously, you’re invisible to the next generation of software consumers.

    The platform convergence is worth watching. Code repositories are evolving from version control into the orchestration layer for the entire software development lifecycle. Whoever controls that layer controls the persistent context that makes agents effective across sessions. The major AI labs are moving toward owning this layer, which suggests the future stack isn’t “AI model plus separate dev tools” but an integrated platform where context, runtime, and code repository collapse into one thing.

    A parallel convergence is happening at the operator level: always-on agents you communicate with through mainstream channels like messaging apps or email rather than terminals or dashboards. The human doesn’t need specialised tooling — they need a channel to the agent that handles everything downstream.

    Combine the GUI agent environment with the always-on operator agent and the platform layer, and you get a full vertical integration play — from software development lifecycle through to production operations, under one roof. This is the smartphone moment for developer tooling: separate apps collapsing into an integrated platform.

    What changes when the stack is purpose built

    The trajectory over the last few years has been clear: model capabilities improve while cost per unit of useful output drops. But today’s pricing is misleading — current subscription tiers are heavily subsidised, much like AWS in 2006. AI companies are burning cash to establish market share. The real story isn’t simply “it gets cheaper.” Provider economics improve toward sustainability while capabilities compound for users. Both curves move in the right direction, but assuming today’s prices reflect true costs is a mistake in either direction.

    Where the stack is unevenly developed matters more than the overall cost trajectory. Code generation has leapt ahead, but DevOps, production support, and operational reliability are further behind — areas where consequences of AI errors are immediate and expensive. The bottleneck isn’t capability. General-purpose coding agents can already manage infrastructure via CLI and APIs. The bottleneck is the trust boundary: giving an agent access to production systems and customer data raises security concerns that don’t exist in a sandboxed branch. Specialised DevOps agents are emerging to address this, but they’ll likely follow the familiar platform-shift pattern — absorbed into general-purpose agents once the sandboxing layer matures.

    There’s an irony in what AI is automating first: not the creative work developers love, but the process work that fell through the cracks as agile teams prioritised working software over documentation. The manifesto was right that heavyweight documentation was wasteful — but in practice, teams swung too far the other way, under-documenting, under-testing, and accumulating technical debt. Agents don’t have that bias. They’ll write tests and documentation with the same attention as feature code.

    What this means now

    Mainstream custom AI chips are a few years out. AI-native frameworks, possibly even shorter. Organisational redesign is the slowest layer — cultural, not technical.

    None of that is a reason to wait. Dark factory teams are already running production workflows on the borrowed stack — and the gap between them and companies still debating AI adoption compounds monthly. Every month of building expertise on today’s imperfect infrastructure is learning that transfers directly to the purpose-built era.

    The early smartphone era produced the apps, habits, and companies that dominated the next decade. We’re in the equivalent moment for AI. The stack will improve. The question is whether you’ll be positioned to take advantage of it.

  • Indian IT’s Arbitrage Problem: When Tokens Cost the Same Everywhere

    The Indian IT services industry was built on a straightforward premise: skilled developers in Bangalore cost significantly less than comparable talent in San Francisco. This differential created an empire — TCS, Infosys, Wipro, and hundreds of smaller firms billing clients based on headcount. The model was self-reinforcing. More engineers meant more revenue, which meant hiring even more engineers.

    AI breaks this equation in a way previous technology shifts didn’t. When an LLM API costs the same per million tokens whether you’re calling it from Mumbai or Manhattan, geography stops mattering. The cost of doing work is shifting from labour, which varies by location, to compute, which doesn’t. As AI agents get better at performing tasks that used to require human engineers, the ratio keeps tilting further away from the headcount model, resulting in a structural break.

    The arbitrage that built an industry

    India’s tech boom worked because clients could get the same capability at dramatically lower cost. A Fortune 500 company could hire multiple engineers in India for significantly less than the cost of one in the US, and the output quality was comparable. Even Global Capability Centres — the in-house versions of this model — followed the same logic, functioning as cost centres to reduce the parent company’s tech spend.

    China’s manufacturing dominance followed the same pattern: cheap labour built the industry, then automation eroded the advantage but the specialised human knowledge persisted. The difference may be speed — manufacturing automation took decades, while AI may be compressing that timeline.

    When uniform pricing changes everything

    Nandan Nilekani described recently how India moved from concept to deployed AI solution for dairy farmers in three weeks — from a January 8 meeting with the Prime Minister to a February 11 launch. That kind of velocity shows what’s possible when AI adoption isn’t constrained by procurement cycles. Large IT services companies, by contrast operate on longer evaluation timelines. By the time a tool clears compliance and gets deployed at scale, the market has moved on.

    This isn’t a process problem that better project management can fix. It’s structural, baked into how large organisations manage risk. Smaller, leaner operations can adopt and discard tools at whatever pace the technology demands. Established players can’t.

    Scale, which used to be the competitive moat, becomes an anchor. When you have large engineering teams on payroll, each person represents fixed costs — salaries, benefits, office space, management overhead. If 10 engineers with AI agents can now produce what 50 engineers produced before, every client will eventually ask why they’re still paying for 50. The “bench” model, where firms keep engineers on payroll between projects, becomes financially unsustainable when margins compress.

    The maintenance trap

    The strongest counterargument came immediately. In February 2026, a short-seller report from Citrini — written as a fictional memo from June 2028 — wiped roughly $10 billion off Indian IT stocks by arguing that cost arbitrage was dead because AI agents run at the cost of electricity. The defence was swift and detailed: Indian IT revenue is overwhelmingly maintenance and integration on legacy enterprise systems, not greenfield coding. Enterprise systems are sprawling, non-monolithic, and require deterministic outputs. AI is probabilistic. You can’t wholesale replace systems of record with something that gives you a different answer every time you ask the same question.

    HSBC estimated 14-16% gross AI-led revenue deflation across service segments — significant but not existential. The technology stacks of the world’s largest enterprises take years to adapt. Custom application maintenance alone accounts for roughly 35% of a typical Indian IT company’s revenue: incident management, service requests, change requests, problem resolution across architectures where SAP, Salesforce, Snowflake, and ServiceNow coexist in configurations unique to each client.

    The problem with this defence: maintenance work is structured, repeatable, well-documented—exactly the kind of work agents may eventually handle well. It’s arguably easier to automate than greenfield development because the patterns are known and the test conditions are defined. Even if 14-16% deflation is accurate, that’s 14-16% less revenue through a headcount-based billing model, which means clients now have a benchmark for what’s possible. The entire pricing structure comes under pressure.

    HFS Research projects a category called Services-as-Software growing to $1.5 trillion — AI-driven autonomous delivery replacing seat-based pricing with outcome-based models. IT service companies proactive about building their own AI agents, and willing to cannibalise legacy revenues, can gain share from software companies rather than just lose it. Companies that defend the old model will likely lose share.

    What survives

    Strategic judgement still matters. Domain expertise still matters. The ability to translate messy business problems into AI-solvable workflows — that doesn’t have a token cost equivalent. Even if code generation gets solved, the compliance, security, infrastructure, and domain knowledge layers don’t collapse. Enterprise software involves SOC-2 audits, data residency, currency handling, PII management. None of that happens automatically. Someone needs to be accountable when things break.

    DevOps, support, and production reliability are further behind code generation in the automation curve. Monitoring, incident response, infrastructure management — the consequences of AI errors in these areas are immediate and expensive. The software development lifecycle may be restructuring fast, but the operational layer still needs human judgment.

    Indian IT’s deep domain knowledge in specific verticals — healthcare, banking, insurance — could be repositioned rather than eliminated. Whether companies can make that pivot before clients start asking harder questions about headcount is the open question.

    The uncomfortable transition

    Headcount-based billing becomes harder to justify every quarter. The bench model becomes financially unsustainable at current margins. GCCs will face pressure to shrink headcount and demonstrate output-per-head improvements. Indian IT may need to pivot from services to products, or reinvent the services model around outcome-based pricing.

    When 59% of hiring managers admit they emphasize AI in layoff announcements because it “plays better with stakeholders” than admitting financial constraints, the narrative gap becomes clear. Companies are restructuring for traditional budget reasons but framing it as AI transformation. That creates a trust problem, but it also reveals something about client expectations: the perception that AI should reduce headcount costs is becoming real, whether or not the technology has fully delivered on that promise yet.

    The same forces dismantling labour arbitrage are creating opportunities for lean operators. A solo developer or small team with the right domain expertise and AI tools can now deliver enterprise-grade output. Clients don’t care if the work was done by 50 engineers in a GCC or 2 people with agents — they care about the outcome. Outcome-based pricing models become viable and attractive: charge for value delivered, not hours spent.

    Indian tech talent is world-class. The individuals who decouple from the headcount model and operate independently or in small setups may be better positioned than ever. The market is shifting from “who has the most people” to “who can deliver the most value per unit of cost” — and that’s a game lean operators can win.

    The question isn’t whether Indian IT survives. The industry isn’t disappearing. The question is whether the organisational models built around labour arbitrage can adapt to value arbitrage fast enough. The talent is there. The domain expertise is there. What’s uncertain is whether companies structured around selling engineer-hours can reinvent themselves to sell outcomes instead—and whether they can do it before clients find someone else who already has.

  • The Autonomous SDLC: What’s Solved, What’s Not, and Why the Gaps Are Closing Fast

    We’re further along than most people realize. The software development lifecycle is being automated piece by piece, and the trajectory is becoming harder to ignore—not through some magical breakthrough, but through the steady elimination of bottlenecks that seemed permanent six months ago.

    This is a practitioner’s status report discussing what works in production today, what remains genuinely unsolved, and why the remaining gaps matter less than conventional wisdom suggests.

    Code Generation: Already Production-Grade

    The middle portion of the SDLC—turning specifications into working code—has crossed a threshold. Cursor CEO Michael Truell describes three eras: tab autocomplete, synchronous agents responding to prompts, and now agents tackling larger tasks independently with less human direction. At Cursor, 35% of merged PRs now come from agents running autonomously in cloud VMs. The agent PRs are “an order of magnitude more ambitious than human PRs” while maintaining higher merge rates.

    What matters isn’t the percentage—it’s that these agent-generated PRs pass the same review standards as human code. Max Woolf’s detailed experiments are instructive. Starting as a vocal skeptic who wrote about rarely using LLMs, he ended up building Rust libraries that outperformed battle-tested numpy-backed implementations by 2-30x. Not prototypes—production code passing comprehensive test suites and benchmarks.

    His conclusion after months of testing:

    I have been trying to break this damn model by giving it complex tasks that would take me months to do by myself despite my coding pedigree but Opus and Codex keep doing them correctly.

    The quality ceiling keeps rising with each model generation. This isn’t “good enough for prototypes”—it’s production-grade code that ships.

    Spec-Driven Development

    The initiation problem has largely converged. Most tools now support planning mode—the agent reads a spec, creates an implementation plan, follows it through. Woolf’s experience matters here:

    AGENTS.md is probably the main differentiator between those getting good and bad results with agents.

    These persistent instruction files function as system prompts that shape agent behaviour across sessions.

    This is just spec-driven development—the same methodology good engineering teams already use. The pattern works: write a detailed spec (GitHub issue, markdown file), point the agent at it, let it execute. The difference is that agents can now be the executor, and the pattern works across tools (Cursor, Claude Code, Codex) because it aligns with how reliable software gets built regardless of who’s typing.

    The Feedback Loop: The Primary Gap

    Basic unit tests and regression tests work well—agents can write and run them as part of their workflow. Complex feature tests, integration tests, and UAT remain the primary gap. UI/UX testing is particularly challenging since agents can’t easily evaluate visual output.

    The current workaround: human-in-the-loop for complex test evaluation, with agents handling mechanical testing. That said, the coding agents can still fix bugs when given screenshots and descriptions.

    This is an active focus area. The gap is narrowing from both sides: agents getting better at generating comprehensive tests, and tooling improving for automated visual and integration testing. Satisfactory solutions within 2026 aren’t a stretch—they’re the natural next step given where the infrastructure is heading.

    Guardrails: Actively Being Solved

    Managing task boundaries and blast radius is critical for autonomous operation. Best practices are emerging around sandboxing—isolated agent execution environments, limited file system access, branch-based workflows.

    The Anthropic C compiler experiment demonstrated the pattern at scale: 16 agents working on a shared codebase over 2,000 sessions, coordinating through git locks and comprehensive test harnesses. The test infrastructure was rigorous enough to guide autonomous agents toward correctness without human review, producing a 100,000-line compiler that can build Linux.

    StrongDM took this further with their dark factory approach. They built digital twins of production dependencies—behavioral clones of Okta, Jira, Slack—using agents to replicate APIs and edge cases. This enabled validation at volumes far exceeding production limits without risk. Their rule: “Code must not be reviewed by humans.” The safety comes from comprehensive scenario testing against holdout test cases the agents never see.

    The agent infrastructure layer is building out fast. We’re seeing microVMs that boot fast enough to feel container-like, with snapshot/restore making “reset” almost free. Agent-specific sandboxed compute, identity, and API access are emerging as distinct product categories.

    The guardrails problem is increasingly an infrastructure problem, not a model problem. This converges toward a standard pattern: spec + guardrails + sandbox + automated validation = safe autonomous execution.

    The Self-Improvement Dynamic

    Something subtle is happening. Codex optimizes code, Opus optimizes it further, Opus validates against known-good implementations. Cumulative 6x speed improvements on already-optimized code. Then you have Opus 4.6 iteratively improving its own code through benchmark-driven passes.

    Folks have showed agents tuning LLMs on Hugging Face—the tooling layer being built by the tools themselves. This isn’t theoretical AGI. It’s narrow but powerful self-improvement within the coding domain. The practical implication: the rate of improvement accelerates as agents get better at improving agents. For the coding stack specifically, each generation of tools makes the next generation arrive faster.

    What This Means for Planning

    Here’s the timeline as I see it:

    2025: Code generation reliable. Spec-driven development emerging. Testing and guardrails manual.

    2026: Testing automation reaches satisfactory level. Guardrails standardize. The loop becomes semi-autonomous.

    2027+: Fully autonomous for standard applications. Human involvement shifts entirely to direction and edge cases.

    The companies planning as if these gaps will persist are making the same mistake as those who planned around slow internet in 2005. AI tools amplify existing expertise—all the practices that distinguished senior engineers (comprehensive testing, good documentation, strong version control habits, effective code review) matter even more now. But the bar for what “good enough” looks like is rising in parallel.

    Antirez captures the shift plainly:

    Writing code is no longer needed for the most part. It is now a lot more interesting to understand what to do, and how to do it.

    The mental work hasn’t disappeared. It’s concentrated in the parts machines can’t yet replace: architecture decisions, user needs, system design trade-offs.

    The gaps are real today. But they’re the wrong thing to optimize around. Optimize around what becomes possible when they close—because that’s happening faster than the pace of traditional software planning cycles.

  • The Task Changed, The Job Didn’t — But Your Org Hasn’t Noticed Yet

    There’s a conversation happening quietly in engineering teams, product orgs, and design studios. It surfaces in Slack DMs and whispered break-room conversations. The question underneath is always the same: If AI can do what I do, what am I for?

    That fear makes sense. Engineers who built their identity around writing clean code watch AI generate entire modules in seconds. Product managers who prided themselves on writing crisp specs see AI agents do the same work overnight. Designers watch their Figma files get autocompleted before they’ve finished thinking through the problem.

    But here’s what’s being missed: the task is changing, the job isn’t.

    Writing code was always a means to an end. The job was shipping features that solve problems. Writing specs was always a means to an end. The job was understanding user needs and deciding what to build. AI automates the means, not the end. The bottleneck was never typing speed — it was clarity of thinking, problem definition, and judgment about what to build.

    Those bottlenecks are still ours.

    The Identity Trap

    Most people in technology define themselves by the task they perform, not the outcome they produce. “I’m a backend engineer” means I write backend code. “I’m a PM” means I write specs and manage tickets. When AI starts doing those tasks faster and arguably better, the identity feels threatened.

    The first response is usually denial: “AI can’t really do what I do — it doesn’t understand context, it makes mistakes, it needs constant supervision.” The second is panic: “I’m about to be replaced by a model that costs pennies per thousand tokens.”

    But the real shift isn’t about automation replacing roles. It’s about what happens when execution becomes nearly free and the entire competitive advantage moves to knowing what to build in the first place.

    From Tasks to Judgment

    When people ask what humans will do in this new world, the answer is usually “taste and judgment.” But that’s abstract. What does judgment actually mean?

    It means knowing what to build, when to say no, and how to spot when AI is heading in the wrong direction. It’s defining the guardrails before you let agents run — test suites, design patterns, architectural constraints. It’s understanding that every line of code is future maintenance burden, which makes the discipline to not build more valuable than the ability to build fast.

    In 2014, Melissa Perri warned about “The Build Trap” — companies stuck measuring success by what they shipped rather than what they learned. “Building is the easy part,” she wrote. “Figuring out what to build and how we are going to build it is the hard part.”

    Most companies ignored that. Now AI makes building trivially easy, and those companies are about to drown in features that solve nothing. The agents don’t get tired. They don’t push back. They’ll happily build everything you point them at, whether or not it should exist.

    The Multi-Hat Convergence

    The expectation is shifting: one person who can think about the problem, design the solution, and use AI to build it. This doesn’t mean everyone becomes a shallow generalist. It means the boundaries between roles blur significantly.

    PMs without a hard skill — design or code — and engineers without product sense are both increasingly vulnerable. The trifecta of product thinking, design sense, and technical execution is becoming the baseline, not the exception.

    For experienced professionals considering independence, this convergence changes the economics dramatically. A single person with AI tools can now deliver what used to require a small team.

    The Org Structure Problem

    Most organizations are still structured around tasks, not outcomes. Teams are organized by function — frontend team, backend team, QA team, design team. Performance is measured by task completion: PRs merged, tickets closed, specs written.

    AI makes task completion trivially fast, which breaks these measurement systems completely. The real metric should be business outcomes, but most orgs aren’t wired to measure or incentivize that way.

    Companies are starting to notice. Last year, the Shopify CEO asked employees to prove why they “cannot get what they want done using AI” before asking for more headcount. Last week, Block laid off 40% of its workforce — more than 4,000 people. Co-founder Jack Dorsey was direct: “A significantly smaller team, using the tools we’re building, can do more and do it better.”

    A startup with great direction and AI agents beats a startup with mediocre direction and the same agents. A company with 10 people who know exactly what to build beats one with 100 people building everything they can think of.

    The companies still hiring for “more hands” are optimizing for the wrong bottleneck.

    What This Means for You

    If you’re an engineer, invest in product sense and domain expertise. Understand why you’re building, not just how. Study the business side of your domain — unit economics, customer behavior, market dynamics.

    If you’re a PM, get your hands dirty with at least one hard skill. Design or code, even at a basic level. The ability to prototype your own ideas or understand technical tradeoffs without waiting for a meeting makes you more effective than you’d expect.

    If you’re a leader, start restructuring teams around outcomes, not functions. Measure business impact, not tickets closed. Reward people for solving problems and learning, not for producing code.

    Stop identifying with your task. Start identifying with the outcomes you produce.

    The people making this shift now are building a compounding advantage. The gap widens every month. Domain expertise becomes your moat. The deeper you understand a specific business problem space, the better you can direct agents toward solving it.

    The execution bottleneck is being solved. The judgment bottleneck requires human capacity, and it’s where the real value lives now.

  • The Dark Factory: Engineering Teams That Run With the Lights Off

    A few engineering organisations are already operating a model most companies haven’t begun to consider. While the typical software team debates whether to adopt AI coding assistants, companies like StrongDM are running fully automated development pipelines where agents handle implementation, testing, review, and deployment. Humans set direction and define constraints. The mechanical work happens without them.

    This isn’t speculative. It’s operational. And the gap between companies working this way and those that aren’t is widening fast.

    What “lights off” actually means

    The term comes from manufacturing — factories that run autonomously, with minimal human presence. In software, it describes engineering organisations where AI agents do the bulk of execution work while humans focus on architecture, constraints, and outcomes.

    StrongDM’s approach is instructive: their benchmark is that if you haven’t spent at least $1,000 on tokens per human engineer per day, your software factory has room for improvement. Agents work in parallel on isolated tasks. Code is written, tested, and reviewed without manual intervention. Tasks assigned Friday evening return results Monday morning.

    The ratio of agents to humans is high and growing. But this isn’t about replacing engineers — it’s about fundamentally changing what engineers do.

    The guardrails are the system

    Dark factories aren’t ungoverned. They’re heavily governed in a different way.

    Linters, formatters, comprehensive test suites, design pattern enforcement — these become pre-conditions rather than suggestions. Agents are configured to seek completion only when all guardrails pass. Code review shifts from line-by-line human inspection to AI review with human spot-checks on critical paths.

    The discipline moves from “write good code” to “design good systems for code to be written in.” That’s a different skill. It requires thinking about constraints, validation, and feedback loops rather than syntax and implementation details.

    Anthropic’s experiment building a C compiler with parallel Claude instances demonstrates this principle. Sixteen agents worked simultaneously on a shared codebase, coordinating through git locks and comprehensive test harnesses. The result: a 100,000-line compiler capable of building the Linux kernel, produced over nearly 2,000 sessions across two weeks for just under $20,000. The project worked because the test infrastructure was rigorous enough to guide autonomous agents toward correctness without human review of every change.

    Cursor’s experiments with scaling agents ran into a different problem. They tried flat coordination first — agents self-organising through a shared file, claiming tasks, updating status. It broke down. Agents held locks too long, became risk-averse, made small safe changes, and nobody took responsibility for hard problems. The fix was introducing hierarchy: planners that explore the codebase and create tasks, workers that grind on assigned work until it’s done. No single agent tries to do everything. The system ran for weeks, writing over a million lines of code. One project improved video rendering performance by 25x and shipped to production. Their takeaway: many of the gains came from removing complexity rather than adding it.

    Digital twins as the enabler

    The biggest blocker to agent autonomy has been the fear of breaking production. Digital twins remove that constraint.

    StrongDM built behavioural replicas of third-party services their software depends on — Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets. These twins replicate APIs, edge cases, and observable behaviours with sufficient fidelity that agents can test against realistic conditions at volume, without rate limits or production risk.

    Simon Willison’s write-up of StrongDM’s approach highlights how this changed what was economically feasible: “Creating a high fidelity clone of a significant SaaS application was always possible, but never economically feasible. Generations of engineers may have wanted a full in-memory replica of their CRM to test against, but self-censored the proposal to build it.”

    What makes this rigorous rather than just better staging is how they handle validation. Test scenarios are stored outside the codebase — separate from where the coding agents can see them — functioning like holdout sets in machine learning. Agents can’t overfit to the tests because they don’t have access to them. The QA team is also agents, running thousands of scenarios per hour without hitting rate limits or accumulating API costs.

    The structural advantage of starting fresh

    Startups and SMBs have a material advantage here. No legacy organisational structure to dismantle. No 500-person engineering floor with stakeholders defending headcount. No 18-month procurement cycles.

    Capital efficiency becomes native. A three-person team with agents can produce output that previously required twenty people. The cost of compute is a fraction of equivalent human labour and falling rapidly.

    This creates an asymmetric advantage. If your competitor ships in days what takes you months, no amount of talent closes that gap. And the competitive pressure isn’t just on speed — it’s on the ability to attract talent that wants to work this way. Senior engineers who’ve experienced agent-driven development don’t want to go back to manual workflows.

    The gap between adopters and laggards

    Companies operating this way are shipping at a fundamentally different pace. The difference isn’t incremental — it’s orders of magnitude in output per person.

    Block’s recent announcement of a near-50% reduction in headcount offers a data point. The company is reducing its organization from over 10,000 people to just under 6,000. Jack Dorsey stated “we’re not making this decision because we’re in trouble. our business is strong” but noted that “the intelligence tools we’re creating and using, paired with smaller and flatter teams, are enabling a new way of working which fundamentally changes what it means to build and run a company.”

    Cursor’s data shows the same pattern. 35% of pull requests merged internally at Cursor are now created by agents operating autonomously in cloud VMs. The developers adopting this approach write almost no code themselves. They spend their time breaking down problems, reviewing artifacts, and giving feedback. They spin up multiple agents simultaneously instead of guiding one to completion.

    The laggards aren’t just slower. They’re increasingly unable to compete for talent, capital, or market position against organisations that have made this transition.

    You don’t need a corporate budget to start

    The dark factory model scales down. A single developer with a Claude Code subscription and well-structured GitHub workflows can run a lightweight version of the same approach.

    Start with one workflow. Pick a repetitive part of your development or business process, establish the guardrails, and let agents handle it. The key investment isn’t in compute — it’s in guardrails and context. Linters, test suites, good documentation, and clear specifications matter more than token budget.

    For SMBs and founders, this is the most asymmetric advantage available. You can operate at a scale that was previously only accessible with significant headcount. The learning curve is steep but short. Within 30 days of serious experimentation, most people develop the intuition for what agents can and can’t handle.

    Projects like OpenClaw — an open-source autonomous agent that executes tasks across messaging platforms and services — demonstrate that the tooling for this approach is increasingly accessible. The software runs locally, integrates with multiple LLM providers, and requires no enterprise licensing. The barrier isn’t access to technology. It’s willingness to change how work gets done.

    What this means beyond software

    Software is where this pattern is playing out first, but the model applies wherever knowledge work is structured and repeatable.

    Audit processes. Compliance checks. Report generation. Data analysis. Document review. These are all candidates for the same approach: clear specifications, comprehensive validation, and autonomous execution within defined guardrails.

    Most traditional industries haven’t started thinking about this. They’re still debating whether to use ChatGPT for email drafts. The firms that figure out how to apply dark factory principles to their domain will have an enormous advantage over those still operating with manual workflows.

    The lights are already off in some factories. The question isn’t whether this approach will spread. It’s how quickly your organisation recognises that the game has changed.

  • The Judgment Bottleneck: Why Direction Matters More Than Execution Speed

    Watch any software team for long enough and you’ll see the bottleneck move. First it was writing code. Then reviewing it. Then testing. Then deployment. Then security scanning. Each constraint gets automated, and immediately the next one becomes the problem.

    This cycle used to play out over years. Now it’s happening in weeks.

    AI agents can handle spec writing, code generation, reviews, testing, and deployment. The full software development lifecycle for standard applications will be largely automatable within 2-3 years. At that point, everyone has the same execution capability.

    The bottleneck shifts entirely to direction — knowing what to build and where to point these agents.

    What judgment actually means

    When people talk about what humans will get paid for in this new world, the answer is always some version of “taste and judgment.” This sounds right but doesn’t help much in practice.

    What does judgment actually look like?

    At the individual level, it’s watching an agent stream code and knowing it’s heading the wrong way architecturally. At the team level, it’s deciding which features to build and which to kill. At the org level, it’s knowing which markets to enter, which problems to solve, which capabilities to invest in.

    Speed vs quality in judgment

    Most people assume faster judgment is better judgment. This holds true at lower levels — how quickly can you review a PR, decide on an implementation, and move on — but breaks down at higher ones.

    At the strategic level, speed matters far less than quality. A fast bad decision with an army of agents creates massive damage quickly.

    This is the Build Trap at scale. When Melissa Perri wrote about companies getting stuck in constant building mode, the cost of building the wrong thing was wasted engineering time. Now that execution is nearly free, the cost is wasted opportunity plus the maintenance burden of everything you built.

    As Perri puts it:

    Building is the easy part of the product development process. Figuring out what to build and how we are going to build it is the hard part.

    When she wrote that in 2014, most companies weren’t listening. They were too busy measuring success by production of code or product. “What did you do today?” instead of “What have you learned about our customers or our business?”

    Now the stakes are higher. The agents don’t get tired. They don’t push back. They’ll happily build everything you tell them to build, whether or not it should exist.

    Why strategic judgment resists automation

    LLMs are excellent at execution-level tasks. They’re increasingly good at tactical decisions — which design pattern to use, how to structure a module. They’re much weaker at strategic judgment.

    Should we build this product? Enter this market? Restructure this team?

    Strategic judgment requires context that lives outside any codebase: market dynamics, competitive landscape, customer relationships, organisational politics, timing. Digital twins and second brains may help over time, but what questions to ask remains human.

    Software factories are now real. StrongDM AI built one where “specs + scenarios drive agents that write code, run harnesses, and converge without human review.” Their internal guidelines are telling: “If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.”

    But even they aren’t automating direction. They’re automating execution based on specs that humans still write. The factory doesn’t decide what to build. It decides how to build what you told it to.

    What happens when everyone has the same tools

    When everyone has access to powerful AI agents, competitive advantage shifts.

    A startup with great direction and AI agents beats a startup with mediocre direction and the same agents. A company with 10 people who know exactly what to build beats one with 100 people building everything they can think of.

    The industry spent decades competing on execution capacity. The companies still hiring for “more hands” are optimising for the wrong bottleneck.

    Dan Shapiro describes this progression through five levels of automation: from spicy autocomplete to software factory. At Level 3, you become a manager reviewing endless diffs. At Level 4, you’re essentially a PM writing specs. At Level 5, it’s a black box that turns specs into software — a dark factory where humans are neither needed nor welcome.

    But even at Level 5, someone still decides what goes into the black box. That’s the judgment layer that can’t be automated away.

    What this means for you

    Individual engineers and PMs: your value is moving from “can you build it” to “should we build it.” Invest in domain expertise, business understanding, and product sense. Study the business side of whatever domain you work in. Understanding unit economics, customer behaviour, and market dynamics makes you more valuable than knowing the latest framework.

    Startups have an advantage in direction. You can’t outspend incumbents on execution, but you can out-think them.

    Enterprises face a different risk — having a massive agent army pointed at the wrong objectives. Governance and strategy matter more than tooling. Every bad strategic decision gets executed at scale.

    For traditional industries, the judgment layer is where external expertise earns its keep — not in the building, but in the pointing.

    Learning to evaluate and adjust direction

    The most important skill isn’t making perfect decisions. It’s learning to evaluate and adjust direction quickly as you get signal from the market. This is judgment in practice, not in theory.

    Domain expertise becomes your moat. The deeper you understand a specific business problem space, the better you can direct agents toward solving it. Learn to operate at the “what to build” level, not the “how to build” level. Practice defining problems crisply, specifying success criteria, and saying no to features.

    For business leaders, get hands-on with AI tools enough to develop intuition about what they can do. You don’t need to code, but you need to know what’s possible.

    The execution bottleneck is being solved. The judgment bottleneck requires human capacity, and at the highest levels, quality of strategic thinking matters more than speed of decision-making.

    Ask what you’re learning as you move. Ask if you’re building the right things in the first place.

  • 20 years of blogging

    20 years of blogging

    The blog turned 20 in Jan, and as I was looking back at the older posts, I found this draft titled “The farmer and the demon” from a dozen years back that seems quite apt for the current wave of agentic AI and the job market.

    That story about the work hungry demon taken from a book:

    There once was a farmer who was granted a boon of being able to summon a hard working demon to do his bidding. One day he got tired of doing his work and chanted the magic words and lo and behold, there stood a demon in front of him.
    This is a story from Punjab, a state popular for its fertile land and prosperous farmers. This story shows that how prosperity can make people greedy and get them into serious trouble. It also shows that sometimes, when a man is in trouble, it takes a woman to rescue him. The woman helps him out not by a show of strength but by using her head.

    Once upon a time there lived a man called Sher Dil. He was a rich man with acres of farmland and so many heads of cattle he did not know what to do with them. So Sher Dil had engaged a hundred servants to work for him. But Sher Dil was at heart a miser. He hated to spend money feeding the servants and paying their wages.

    Sher Dil`s wife Gulabo was his exact opposite in temperament. She was patient and good natured and very wise. Whenever Sher Dil grumbled about expenses, she rebuked him saying that the servants worked hard for thgem throughout the year. Hence there was nothing wrong in paying them their deserved wages. On the contrary Sher Dil should be grateful for all that the great Lord has given them. But her words of wisdom had no effect whatsoever on her ill tempered, miserly husband.

    One day Sher Dil sat down to do his accounts and sure enough, he soon started grumbling about the expenses that the servants incurred. He said that he will employ only one person for all the work. However his wife protested. Sher Dil had the wicked idea of employing a demon instead of several human beings for the work. The more he thought over this idea, the more he liked it. And Sher Dil made up his mind to visit a sadhu who granted boons to people and put an end to their troubles.

    It took Sher Dil two days to reach the sadhu`s hut, situated in the middle of a forest. The sadhu sat deep in meditation. At long last he opened his eyes and asked Sher Dil what he had come for. Sher Dil bowed his head and expressed his desire. The sadhu granted his wish. He picked up a stick, closed his eyes and murmured something. Then he drove the stick into the ground. Next minute a thin stream of smoke began to emerge from the top end of the stick. Slowly the stream increased in volume till it became a small cloud, rumbling like thunder. And out of the cloud stepped a huge, blue-coloured demon as tall as a pipal tree. He looked so fierce that Sher Dil felt like running away. But somehow he stood his ground. The demon roared and asked why he has been summoned. When the sadhu explained the cause the demon roared again and enquired whether Sher Dil knew the terms of his employment. He must be kept busy throughout the day and night. The moment he finds no work he will eat up Sher Dil.

    Sher Dil burst out laughing and said there is so much of work that he won`t have a minute to spare. Then he instructed the demon to take him home. The words were hardly out of his mouth when the demon snatched him up, tucked him behind one ear and went flying across the sky. Afraid of rolling off, Sher Dil clutched the demon`s ear with both hands and peeped over it. The earth appeared like a tiny multicoloured ball. Sher Dil closed his eyes for fear. Then suddenly the demon began to descend like an egg thrown up in the air. He touched down at Sher Dil`s own doorstep. Sher Dil scrambled off and ran to see his wife. Bursting with excitement he showed his wife what he had found.

    Before his wife could say anything in reply, Sher Dil had sacked all his servants and sent off the demon to plough the land. Then he yawned, stretched himself and lay down on his bed for a nice little nap. Sher Dil was in the middle of a rosy dream when someone grabbed him by the shoulder and shook him hard. As he opened his eyes he saw the demon towering over him. He was asking for more work. Sher Dil could not believe his ears. So many acres of land, ploughed up in less than a quarter of an hour! He climbed to his roof and looked around to be sure the land had been ploughed as far as the eye could see. Then he ordered the demon get some manure and mix it with the soil, sow the seed and water the fields.

    The demon disappeared and Sher Dil went back to sleep again. But he had barely snored a couple of times when someone shook him again, harder than before and again asked for work. By this time Sher Dil was quite irritated and said him to raise a fence all around his land. The demon left but Sher Dil did not go back to sleep again. From his kitchen window he watched the demon fetch a pile of wood and some tools. His hands flew as one stick after another was cut and shaped and driven into the ground. Before Sher Dil had finished his evening cup of tea the demon was back again.

    Sher Dil sent him off to empty out their pond and fill it with fresh water from the river. Night was falling when the demon returned to say that the work had been done. In despair Sher Dil asked him to rest but the demon laughed, a horrible, croaky laugh saying that he never rested. Sher Dil picked up courage enough to say that he wanted to rest till the next morning. In the meantime he asked the demon to guard the fields so no wild animal can get in and trample down the seed.

    The demon went away but Sher Dil could not sleep a wink. Just before dawn he woke up his wife and in a tearful state shared his problem. Gulabo comforted him and asked him to leave everything at her discretion. As soon as the sun peeped over the horizon, the demon began to hammer at the door. `Work,` he yelled. Gulabo opened the door a crack and peeped out. Then she came out of the door. She asked the demon to straighten the tail of a stray dog that often came there looking for food.

    The demon bent down, caught the dog`s tail by the tip and gave it a good jerk. The tail straightened out. But the moment he let go, it curled up again. The demon caught the tail a second time and stroked it for a good five minutes. But the moment he let go, the tail curled up again. With a frown on his face the demon caught the tail for the third time, rolled it up the other way and held it in position for some time. As soon as he let the tail go it curled up again, back to its original shape.

    All this time the dog had been watching patiently as the demon fiddled around with its tail. But suddenly it lost its patience. With a bound it was up and barking at the demon. Round and round they went, the demon dodging and ducking and diving at the tail and the dog snapping and snarling and threatening to bite. This went on for hours. In the end the demon got fed up of trying to catch the dog. He admitted to himself that he cannot do the assigned work. But he was thoroughly ashamed of himself at the same time. He had no courage to face the family. So off he went to hide in the forest that he came from.

    With the demon gone, Sher Dil and his wife began to live in peace once again. Sher Dil took back all his servants and gave them a solid feed to start with. And never, never again did he complain about the amount that he had to spend on their food and wages.

  • Turning 42, and Coming Full Circle

    Turning 42, and Coming Full Circle

    I turned 42 this year. I don’t usually attach much meaning to birthdays, but this one did trigger a quiet pause—not a reinvention, not a reset, just a sense of recognition. A feeling that certain instincts and interests I’ve carried for a long time were finally meeting the right conditions to be acted upon.

    In many ways, it felt like coming full circle. Post–IIT Bombay, I had toyed with the idea of building something of my own more than once, but the timing never really worked. The cost of experimentation was high, the downside felt asymmetric, and meaningful execution required a kind of commitment—in time, capital, and headspace—that didn’t quite align with where life was then. AI didn’t create those ambitions. It removed enough friction that acting on them no longer felt irresponsible.

    There’s a popular mental model floating for AI—the Star Trek computer. Voice interface, simple commands, complex tasks executed seamlessly. It’s appealing: tell the AI what you want, and it handles the messy details. But we don’t have that yet. What we have now is quite powerful but far messier—and that gap between expectation and reality matters.

    Looking back, this arc probably started earlier than I realized. What felt like casual tinkering at the time—experimenting with tools, workflows, and ways of interacting with information—was really the beginning of a longer loop of building, reflecting, and writing.

    ⸻

    The first half of the year was deliberately focused inward. The arrival of our newborn changed the rhythm of everyday life in fairly fundamental ways. Time became scarcer, but priorities became clearer. Decisions that once felt nuanced or debatable started resolving themselves quickly when viewed through the lens of family well-being and long-term sustainability.

    Around the same time, we moved from Dubai back to Mumbai. On paper, it was a relocation. In practice, it was a broader reset—of cost structures, support systems, and optionality. Some things became simpler, others more complex, but overall it created a sense of grounding that had been missing.

    In hindsight, the first half wasn’t a slowdown so much as an incubation period. That stability mattered more than I realized at the time, because once the personal base felt settled, professional decisions became easier to make—and easier to commit to. The questions that kept surfacing during this phase were telling. Education, work, and what we’re really preparing the next generation for stopped feeling abstract and started feeling personal. Agency matters more than intelligence—the capacity to take initiative, make things happen, shape your path rather than wait for it. Are we educating for that? It’s a question that feels more urgent when you’re thinking about your own child’s future.

    ⸻

    The second half of the year marked a clear shift from exploration to ownership. I chose to go down the solo path, not because it’s easier, but because at this stage it offers speed and coherence. Fewer dependencies, tighter feedback loops, clearer accountability.

    AI changed the feasibility equation in a very real way. What once required teams and capital can now be prototyped solo—not perfectly, but fast enough to learn. Over time, this also changed how I approached building itself, gravitating toward a more fluid, iterative style where intent and execution sit much closer together.

    That conviction led to formalizing OrchestratorAI. Registering the company and filing the trademark weren’t about signaling externally as much as they were about drawing a line for myself. This wasn’t just advisory work or experimentation anymore; it was something I wanted to build patiently and seriously.

    A lot of the focus naturally gravitated toward the long tail—especially MSMEs. Large enterprises will adopt AI, but slowly and expensively. Smaller businesses can leapfrog. The marginal cost of intelligence has dropped enough that problems once considered too small or not worth solving suddenly are. That idea kept resurfacing as I looked at broader patterns in work, strategy, and go-to-market, often in ways that felt far messier in practice than in slides.

    Completing a year self-employed felt like its own milestone—not because of what I’d built yet, but because I’d committed to the path.

    ⸻

    Three things that have crystallized

    This is a great time for builders—not for shortcut-seekers.

    There’s a popular narrative that AI is about doing less work—the Star Trek computer fantasy where you state your intent and complex systems just work. My experience has been the opposite. We don’t have the Star Trek computer. AI rewards those willing to go deeper, not those trying to bypass fundamentals.

    Tools amplify intent and effort; they don’t replace them. The gap between “prompting” and actually building systems—workflows, artifacts, and feedback loops—is widening.

    Jevons’ Paradox is no longer theoretical in knowledge work.

    Making intelligence cheaper doesn’t reduce the amount of work; it expands it. Lower costs unlock suppressed demand—more ideas get tested, more workflows get built, more edge cases start to matter.

    Entire categories of previously unsolvable problems suddenly become economically viable. We’re even seeing fundamental business model shifts—from selling seats to selling outcomes, from “buy software” to “hire agents.”

    This is the foundation of what I’m building: serving markets that were previously uneconomical to serve.

    A lot of old ideas are finally working the way they were meant to.

    State machines, artifact-centric design, structured workflows, even the promise of auto-coding—none of these are new concepts. What’s new is that the economics finally make sense.

    But there’s also a new layer to master. Programmers now need mental models for agents, subagents, prompts, contexts, tools, workflows—a fundamentally new abstraction layer intermingled with traditional engineering.

    Abstractions still leak, and much of the year’s noise around agentic coding oscillated between hype and reality before settling. What’s emerging: structure matters, and there’s a real shift as agents become central to how work gets done.

    ⸻

    One curious footnote

    Starting in September, I noticed an unusual spike in traffic to my blog—specifically to posts from 10-15 years ago. The pattern was unmistakable: China. Most likely LLM training runs scraping old content at scale.

    There’s something quietly amusing about that timing. While my decade-old posts were feeding tomorrow’s AI models, I was using today’s AI to finally act on ideas I’d shelved post-IITB. Full circle, in an unexpected way.

    ⸻

    2026 feels different. Not because the work gets easier, but because the constraints are clearer. Family grounded, venture formalized, year one complete.

  • Baahubali: The Epic

    Baahubali: The Epic

    Been a while since I posted a movie review on the site, and also watched a movie in the renovated IMAX theatre in our neighbourhood. What better movie to watch on the large IMAX screen than a release of the combined Baahubali movie.

    Despite clocking in at nearly 4 hours (which makes it just as long as Lagaan), the film remains as fast paced and thrilling as it was originally. In fact the major cuts are to the songs and some of the filler scenes which actually go by faster.

    We watched the Telugu version which had English subtitles, not that you need language to appreciate the movie. The theatre was pretty much filled with fans of the series given the scream and whistle reactions upon the entry of the stars and the key scenes. That’s something you miss while watching at home for sure.

    The action scenes were just as spectacular, and getting to watch Dhivara on the big screen once more was worth it. So, do catch it in the theatres if you get the chance, and the film is edited assuming that you have watched the original parts given WKKB scene being part of the opening sequence itself.

  • From Clicks to Conversations: How AI Agents Are Revolutionizing Business

    From Clicks to Conversations: How AI Agents Are Revolutionizing Business

    For the last decade, businesses have invested heavily in “Digital Transformation,” building powerful digital tools and processes to modernize their operations. While this era brought significant progress, it also created a persistent challenge. The tools we built—from CRMs to ERPs—were largely dependent on structured data: the neat, organized numbers and categories found in a spreadsheet or database. Computers excel at processing this kind of information.

    The problem is that the most valuable business intelligence isn’t structured. The context behind a business plan locked in a 100-slide presentation, the nuance of a customer relationship captured in a rep’s notes, or the true objective of a strategy discussed in a meeting—this is all unstructured data. This divide has created a major hurdle for business efficiency, as great ideas often get lost when people try to translate them into the rigid, structured systems that computers understand.

    The Old Way: The Limits of Traditional Digital Tools

    The first wave of digital tools, from customer relationship management (CRM) software to accounting platforms, were designed for humans to operate. Their critical limitation was their reliance on structured data, which forced people to act as human translators. A brilliant, nuanced strategy conceived in conversations and documents had to be manually broken down and entered into rigid forms and fields.

    This created a significant “gap between business strategy and execution,” where high-level vision was lost during implementation. The result was heavy “change management overheads,” not just because teams needed training on new software, but because of the cognitive friction involved. People are used to working with the unstructured information in their heads; these tools forced them to constantly translate their natural way of thinking into structured processes the software could understand.

    Information TypeBusiness Example
    StructuredEntries in a CRM database, financial data in an accounting platform, inventory numbers in an ERP system.
    UnstructuredA 100-slide brand plan document, a sales rep’s recorded notes describing a doctor they just met, emails discussing a new brand strategy.

    This reliance on structured systems meant that the tools, while digital, couldn’t fully grasp the human context of the work they were supposed to support. A new approach was needed—one that could understand information more like a person does.

    A Smarter Way: Introducing AI Agents

    Welcome to the era of “AI Transformation.” At the heart of this new wave are AI Agents: specialized digital team members that can augment a human workforce. Think of them as a dedicated marketing agent, a sales agent, or a data analyst agent, each designed to perform specific business functions.

    The single most important capability of AI agents is their ability to work with both structured and unstructured information. You can communicate a plan to an agent by typing a message, speaking, or providing a document—just as you would with a human colleague. This fundamental shift from clicking buttons to holding conversations unlocks three profound benefits:

    • Bridging the Strategy-to-Execution Gap: AI agents can understand the nuance of an unstructured plan—the “why” behind the “what”—and help execute it without critical information getting lost in translation.
    • Handling All Information Seamlessly: They can process natural language from documents, presentations, or conversations and transform it into the actionable, structured data that existing digital tools need to function.
    • Reducing Change Management: Because agents understand human language, the need for extensive training on rigid software interfaces is significantly reduced. People can work more naturally, supervising the agents as they handle the tedious, structured tasks.

    To see how this works in practice, let’s walk through how a team of AI agents can help plan and execute a marketing campaign from start to finish.

    AI Agents in Action: Launching a Marketing Campaign

    This step-by-step walkthrough shows how AI agents can take a high-level marketing plan from a simple idea to a fully executed campaign, seamlessly connecting unstructured strategy with structured execution.

    1. The Starting Point: The Marketing Brief – The process begins when a brand manager provides a marketing brief. This brief is pure unstructured information—it could be a presentation, a document, or even the transcript of a planning conversation. It contains the high-level goals and vision for the campaign.
    2. Deconstructing the Brief: The Brand Manager Agent – A specialized “Brand Manager” agent analyzes the unstructured brief and extracts the core business context elements. It identifies key information such as:
      • Business objectives
      • Target audience definitions
      • Key messages
      • Brands in focus
      • Timelines and milestones
    3. The agent then organizes this information into structured, machine-readable “context blocks,” creating a clear, logical foundation that other systems and agents can use.
    4. Understanding the Customer: The Digital Sales Agent – Next, a “Digital Sales” agent contributes by performing customer profiling. It can take unstructured, natural language descriptions of customers (for instance, from a sales rep’s recorded notes) and map them to formal, structured customer segments and personas. This builds a richer, more accurate customer profile than a simple survey could provide.
    5. Creating the Content: The Content Writer Agent – Using the structured business context from the Brand Manager agent, a “Content Writer” agent assembles personalized content. It can reuse and repurpose existing content from a library of approved modules, accelerating content creation while ensuring brand compliance.
    6. Executing the Plan: The Next Best Action (NBA) Engine – Finally, the system brings everything together to recommend the “Next Best Action.” This engine synthesizes the campaign’s business context, the customer’s profile, the available content, and their recent engagement history to suggest the perfect next step for each customer. It recommends precisely what content to send and which channel to use, turning high-level strategy into a concrete, personalized action.

    This orchestrated workflow makes the entire process smoother, faster, and far more intelligent. It creates a virtuous cycle, where the system learns from every interaction to continuously improve the overall strategy and execution over time.

    The Future of Work is Collaborative

    The rise of AI agents marks a fundamental shift in how we work with technology. We are moving from a world where humans must adapt to operate digital tools to one where humans supervise intelligent AI agents that use those tools on our behalf.

    This new wave of AI transformation is not about replacing people, but about augmenting their human workforce without adding headcount. By handling the translation between unstructured human ideas and structured digital processes, AI agents help businesses reduce friction, cut down on turnaround times, and finally bridge the long-standing gap between their biggest strategies and their real-world execution.