Scale Forem: Nick Talwar

Why Engineering-Led AI and Agent Initiatives Collapse in Production

Nick Talwar — Tue, 17 Mar 2026 11:40:35 +0000

The staffing and governance gaps that turn working demos into unmaintainable systems

Your engineering team just showed off a new AI feature, and everyone left the room feeling good about the future of the initiative.

But fast forward three months and the system is crashing twice a week. The team is spending weeks trying to reproduce bugs that only appear in production.

In my time as a fractional CTO serving AI-first organizations, I’ve noticed that many companies structure AI projects the same way they structure any other software build. Leadership sets a roadmap, hands it to engineering, and expects execution to follow the usual patterns.

However, the underlying assumption here is that building intelligent systems follows the same rules as building deterministic ones. This assumption kills most AI initiatives within six months of launch.

The Talent Gap Shows Up Too Late

Machine learning systems break three key assumptions:

Predictable behavior
— A model that returns one answer today might return a different answer tomorrow given identical input.
Testable edge cases
— Edge cases don’t come from a finite list of scenarios you can test against. They emerge from novel combinations of features your training data never represented.
Debuggable logic
— When something fails, you can’t just step through the code to find the bug because the decision logic was learned through statistical optimization, not explicitly programmed.

Your engineering team wasn’t hired to handle probabilistic systems. They won’t naturally catch biased training data, misleading accuracy metrics, or model architectures that can’t explain their predictions. That requires ML expertise.

These aren’t skills you can pick up by reading documentation. They come from building and breaking enough ML systems to recognize patterns that lead to failure.

All too often, teams don’t realize they need these skills until it’s too late. By that time, you’re hiring someone to audit months of work and explain which architectural decisions need to be unwound.

Senior ML engineers know which approaches create technical debt you can’t maintain, which data quality problems cause drift, and which evaluation strategies mislead you during development. They catch these issues before roadmaps lock and budgets get allocated, not after engineering has already committed to the wrong direction.

Demos That Look Great Until Production

Demos operate in carefully controlled environments. The team selects clean input data, constrains the problem space to tested scenarios, and tunes prompts until the output looks impressive.

Under these conditions, AI and Agentic systems seem remarkably capable.

Production removes every safety rail. Real users submit malformed inputs and unexpected data formats. Your data pipelines fail intermittently for reasons that don’t show up in logs. Third-party APIs change their response formats without warning. Models encounter distribution shifts (patterns in the data that differ fundamentally from training data) and produce outputs ranging from subtly wrong to completely nonsensical.

Faced with these issues, an inexperienced engineering team will add retry logic, improve logging, and write better error handling. These help at the margins, but won’t fix what the team doesn’t understand.

Without instrumentation built specifically for model behavior, you’re stuck just treating symptoms. The system logs show normal operation. The model is still running. But somewhere between input and output, quality degraded in ways you never instrumented for.

This is where the lack of ML expertise during architecture becomes expensive. ML engineers build observability into the system from the start because they know models behave unpredictably in production. They instrument confidence thresholds, track prediction distributions, monitor for data drift, and create alerts when model behavior deviates from expected patterns.

Without that foundation, you’re trying to add monitoring for problems you don’t fully understand while simultaneously keeping a broken system running.

What Actually Needs to Change

The very first thing teams should do is bring in a senior ML or data science lead before finalizing the roadmap. You need ML expertise in decision-making before commitments happen, not after engineering has spent two months building in the wrong direction.

Build your operating model around daily collaboration between ML and engineering, not sequential handoffs. The traditional approach where product writes specifications, engineering builds features, and ML practitioners “add intelligence” creates silos that guarantee failure. ML engineers need to work directly with the people building data pipelines, API interfaces, and monitoring systems. These components depend on each other in ways that don’t map to separate work streams.

Establish governance before launch, not after the first incident. Define explicit boundaries: which predictions execute automatically, which require human review, and which should fail safely rather than guess. Implement monitoring that tracks model behavior, confidence score distributions, and output quality trends over time. Create clear escalation paths so when something breaks (and it will) there’s an obvious owner who can diagnose root cause and implement fixes.

This feels like overhead until you ship without it and realize nobody can answer basic questions about system behavior.

Build Systems That Actually Work

Team composition should match the problem:

ML engineers bring expertise in navigating probabilistic systems and understanding where models break.

Software engineers bring discipline around building maintainable infrastructure that operates at scale.

Product brings judgment about where automation creates value and where it introduces unacceptable risk.

All three perspectives need equal weight in planning. Companies that understand this stop launching impressive demos that collapse under real-world load. They build reliable systems that work consistently because they planned for production complexity from day one.

Get the team structure, governance, and collaboration patterns right, and technical challenges become tractable. Skip these foundational changes, and engineering will keep building systems that work beautifully until the moment they encounter reality.

…

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.

→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.

→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

The #1 Reason Agentic AI Fails in Production

Nick Talwar — Tue, 10 Mar 2026 11:52:03 +0000

What happens when you let the LLM make every decision in Agentic AI use cases (and how to fix it)

A few months ago, I watched a Series B startup demo their “production-ready” Agentic AI system. In testing, it worked just fine. But when they gave it real users and edge cases started appearing, the behavior became unpredictable.

The issue was architectural: they’d given the LLM complete autonomy over execution decisions, and LLMs simply aren’t built to provide deterministic control at that level.

Gartner predicts that over 40% of Agentic AI projects will fail to reach production by 2027. The difference between systems that scale reliably and those that collapse under real-world conditions comes down to whether you separate reasoning from execution.

Where Failures Actually Originate

The latest LLMs demonstrate remarkable reasoning capabilities. They can break down complex tasks, weigh tradeoffs, and generate sophisticated action plans. The problem emerges when organizations confuse reasoning capability with execution reliability.

LLMs are probabilistic pattern matchers trained on text. These characteristics propagate to Agentic AI systems built on top of LLMs. They excel at understanding context and generating plausible responses. But they struggle with deterministic execution, maintaining consistent behavior across edge cases, and guaranteeing the same output given similar inputs. Even when they appear to be well understood during pre-production testing and simulation.

Zenity Labs found that classifiers fail when inputs take unexpected paths through activation space. The classifier works perfectly on inputs it recognizes, but novel paths (even semantically similar ones) can produce completely different classifications. The same dynamic applies to Agentic AI: systems trained and tested on known scenarios encounter unfamiliar patterns in production, and their responses become unpredictable.

When you let the LLM make execution decisions directly, you’re betting that production will only present scenarios the model has learned to handle reliably. That bet fails more often than teams expect.

Full Autonomy Creates Unpredictability

In production environments, Agents don’t receive clean, well-formatted inputs. They encounter ambiguity, partial information, conflicting signals, and edge cases that fall outside training distributions.

Consider an Agent tasked with processing refund requests. In testing, requests follow predictable patterns. In production, you get:

Requests that qualify for refunds but use non-standard phrasing
Borderline cases where policy interpretation matters
Situations requiring escalation that don’t match trained escalation triggers

Inputs that combine multiple issues in ways the model hasn’t seen
When the Agent has full autonomy, it must decide in real-time which action to take. Small variations in input phrasing can trigger entirely different action sequences. Run the same ambiguous request twice, and you might get different outcomes. This happens not because the model is malfunctioning, but because probabilistic systems don’t guarantee determinism.

This behavior compounds across interactions. An Agent processing hundreds or thousands of decisions daily will inevitably encounter scenarios that push it outside reliable operating ranges. Without external controls, there’s no mechanism to catch these situations before they produce incorrect actions.

The Control Layer Solution

The Control Layer architectural fix separates what LLMs do well (reasoning) from what they do poorly (deterministic execution).

In this model:

The Agent analyzes the situation and proposes an action
A control layer validates whether that action is permitted
Only validated actions execute

The control layer uses rule-based logic that encodes business constraints, compliance requirements, and operational boundaries. When the Agent proposes an action, the control layer checks:

Does this action fall within permitted operations?
Do the action parameters meet safety constraints?
Are required conditions satisfied?
Does the user context allow this operation?

If validation passes, the action executes. If not, the Agent receives feedback and can propose an alternative. Taking time to address these questions as a team, distill it into requirements, and then work with engineering to distill them into a Control Layer architecture is a core mitigation strategy for these business risks.

This architecture maintains the Agent’s flexibility while ensuring predictable boundaries. The Agent can still reason about complex scenarios and adapt to novel situations. The control layer ensures that adaptation happens within defined limits.

The Right Level of Control

Building systems that consistently do the right things matters more than maximizing autonomy.

Control layers define boundaries that let Agents operate confidently within them. Inside those boundaries, Agents can be remarkably flexible, adapting to novel scenarios and learning from outcomes. The boundaries simply ensure that adaptation doesn’t violate business requirements or create unpredictable behavior. It also gives you a backstop to monitor and close feedback loops, slowly improving the system over time so less escalations occur.

Organizations that skip this step typically discover the need for controls after production failures. By then, retrofitting governance becomes significantly harder than building it from the start (akin to putting a genie back in a bottle).

The systems that succeed in production share a common architecture: they separate reasoning from execution, maintain clear decision boundaries, and enforce validation before actions reach production systems. That architectural choice (more than model selection, training approach, or testing strategy) determines whether Agentic AI delivers predictable value or unpredictable failures.

.…

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.

→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.

→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

8 Core Constraints for Building Production-Grade AI Agents

Nick Talwar — Sun, 01 Mar 2026 19:11:31 +0000

The engineering requirements most teams ignore

Most AI agent implementations fail between prototype and production. Teams focus on conversational fluency and assume the LLM (underneath each Agent) handles complexity. Then they deploy, and realize the system wasn’t built to run reliably.

Agents are stateful, tool-orchestrating systems that operate across multiple services and failure domains. They require explicit architectural constraints at every layer, from how state persists between turns to how tools enforce security boundaries.

This list covers the eight foundational constraints required for agents to run reliably in production environments where observability, recoverability, and maintainability matter more than demo magic.

1. Explicit State Management Architecture

Agents maintain context across multi-turn workflows, often spanning minutes or hours. State management determines whether that context survives failures, supports concurrent sessions, or creates race conditions that corrupt data.

Production agents require persistent state stores with transactional semantics. In-memory state works for development but disappears on restart. External stores like Redis, Postgres, or vector databases provide durability. The architecture must define checkpoint boundaries where state snapshots are persisted, enabling recovery from interruptions or system crashes without losing workflow progress.

Agents handling multiple users simultaneously need session isolation to prevent cross-contamination. The state schema must version transitions to support rollback when agents make incorrect decisions that require human override.

2. Deterministic Tool Interface Contracts

Tool contracts must define exact input schemas, output formats, and failure modes. JSON schemas with strict type validation prevent the agent from passing malformed parameters. Return values need consistent structure, whether success or error, so the agent’s reasoning layer can parse results reliably. Omitting error handling creates black holes where tool failures cascade into hallucinatory responses instead of graceful degradation.

Tool descriptions matter more than most teams assume. The agent uses these descriptions to decide when and how to invoke each tool. Vague descriptions produce incorrect tool selection. Precise descriptions that include constraints, prerequisites, and side effects guide the agent toward correct behavior. For example, a database query tool should specify read-only vs write permissions, maximum result set size, and timeout behavior.

Idempotency becomes critical for tools that modify state. If the agent retries a failed API call, the tool should handle duplicate requests without double-charging, double-booking, or creating duplicate records. Either implement idempotency keys at the tool layer or design tools to check state before executing write operations.

3. Testable Prompt Design and Versioning

Prompts are code. They define agent behavior, and like code, they change frequently. Without versioning and testing, prompt updates break production agents in ways teams discover only through user complaints.

Each deployment should reference a specific prompt version with rollback capability. Changes should go through diff reviews where teams evaluate how modified instructions affect agent reasoning. Semantic versioning applies here as well: minor tweaks get patch versions, instruction changes get minor versions, and persona overhauls get major versions.

Testing prompts requires adversarial scenarios beyond happy paths. Agents need guardrails against prompt injection where user input attempts to override system instructions. Test cases should include malformed inputs, edge cases that expose reasoning gaps, and scenarios where the agent should refuse to act. Evaluation frameworks that score prompt versions against test suites enable objective comparison before deployment.

Prompt complexity compounds maintenance burden. Long system prompts with dozens of edge case instructions become brittle and contradictory. Factor complex prompts into modular components where base instructions handle general behavior and tool-specific prompts augment reasoning for particular contexts. This reduces prompt debugging from parsing 5000-token blocks to isolating which module broke.

4. Scoped Memory Architectures with Retention Policies

Memory determines whether agents provide personalized, context-aware responses or repeat themselves like stateless chatbots. But unmanaged memory becomes a liability where agents over-index on outdated information or leak sensitive data across sessions.

Three scopes matter here. User-level memory stores preferences and historical context specific to an individual. Session-level memory handles current conversation state that should expire after task completion. System-level memory tracks operational metadata like feature flags or configuration changes affecting all agents. Mixing these scopes is where things break. Privacy violations when session data bleeds into system memory, performance issues when user context loads globally.

None of this works without retention policies. Conversation history might keep the last 50 turns with automatic summarization of older content. Personal preferences persist indefinitely but should support deletion for compliance. Skip this step and memory stores grow linearly with usage until queries slow to a crawl. Every piece of stored memory needs a defined lifespan or an explicit reason to persist.

Then there’s the retrieval problem, and it’s the one most teams underestimate. When an agent has thousands of past interactions, pulling all of them for every query tanks both latency and relevance. Semantic search over embedded memories solves this by surfacing only what’s contextually useful. Layer in ranking by recency, relevance, or explicit user priority, and agents start behaving less like databases and more like colleagues who actually remember what matters.

5. Comprehensive Observability and Tracing

Production agents fail in ways demos never encounter. Without observability, debugging becomes guesswork where teams reproduce issues locally but can’t diagnose production failures.

Distributed tracing captures the full execution path. Each agent decision, tool call, and LLM invocation becomes a span with timing data, inputs, outputs, and metadata. Nested spans show hierarchical relationships where a high-level task decomposes into subtasks. This visibility turns opaque failures into clear sequences showing exactly where and why the agent diverged from expected behavior.

Metrics track operational health. Token usage per request prevents runaway costs. Latency distribution identifies slow operations that degrade user experience. Error rates by tool or reasoning step highlight specific failure modes. These metrics feed into dashboards where teams monitor production agents and set alerts for anomalies.

Logging complements tracing with semantic events. When an agent makes a decision, log the reasoning steps and confidence scores. When a tool call fails, log the error and the agent’s recovery strategy. Structured logs with consistent schemas enable aggregation and analysis across thousands of agent sessions, revealing patterns that individual traces miss.

6. Guardrails and Safety Boundaries

Agents with unrestricted access to tools become security liabilities. Guardrails enforce what agents can and cannot do, preventing both accidental misuse and malicious exploitation.

Input validation happens before reasoning. User prompts should pass through filters that detect prompt injection attempts, personally identifiable information, or requests that violate usage policies. Agents should never receive raw, unvalidated input directly from external sources. Preprocessing layers sanitize inputs and reject requests that exceed safety thresholds.

Output validation prevents harmful responses. Even when reasoning appears sound, agent outputs should go through guardrails checking for toxicity, bias, hallucinated facts, or leaked secrets. Automated checks combined with sample-based human review catch issues before users encounter them.

An agent should only invoke tools necessary for its designated tasks. Role-based access control maps agent roles to permitted tool subsets. For example, a customer support agent might query databases but never write to them. An internal automation agent might trigger workflows but never access customer data. Enforcing these boundaries at the orchestration layer prevents privilege escalation.

7. Error Handling and Graceful Degradation

How an agent handles failures determines whether it recovers gracefully or collapses into unusable states.

Retry logic with exponential backoff handles transient failures. If a tool call fails with a 503 error, the agent should retry after a delay rather than immediately halting. But retries need circuit breakers to prevent cascading failures where repeated attempts overload already struggling services. After consecutive failures, the circuit opens and the agent switches to degraded mode.

Fallback strategies maintain functionality when primary paths fail. If real-time data retrieval fails, the agent can fall back to cached data with appropriate disclaimers about staleness. If the preferred LLM provider is unavailable, routing to an alternative model allows continued operation with possibly reduced quality. Explicitly designed fallbacks prevent complete service outages.

When automated recovery fails, agents should recognize their limitations and request human intervention. This requires defining escalation triggers based on confidence scores, repeated failures, or task criticality. Clear handoff protocols ensure humans receive sufficient context to take over without starting from scratch.

8. Security Controls for Tool Execution

Tools give agents power to act on external systems. Without security controls, compromised agents or malicious inputs can cause real damage.

Authentication and authorization apply to every tool invocation. Agents should authenticate to tools using credentials scoped to specific operations. OAuth tokens, API keys, or mutual TLS certificates ensure only authorized agents access sensitive resources. Credentials should never appear in prompts or logs, stored instead in secure vaults with automatic rotation.

Data validation prevents injection attacks. When agents construct SQL queries, API requests, or shell commands, parameterized inputs prevent injection. Never interpolate user input directly into executable statements. Sanitization layers validate data types, ranges, and formats before tools process them.

Audit trails track every tool execution. Who invoked which tool, with what parameters, at what time, and with what result should be immutably logged. These audit logs support security investigations, compliance requirements, and forensic analysis when things go wrong. Retention policies must balance storage costs against regulatory and operational needs.

Rate limiting protects against abuse. Agents might loop on tool calls or malicious inputs might trigger excessive API usage. Per-agent, per-tool, and per-user rate limits prevent runaway resource consumption. Adaptive limits that adjust based on historical behavior provide flexibility while maintaining safety boundaries.

Constraint-First Design as Production Requirement

Production-grade AI agents require constraint-first design. The conversational interface obscures the fact that these systems persist state, orchestrate tools, and make decisions affecting real operations. Each constraint in this list addresses a failure mode that becomes evident only after deployment, when agents face concurrent users, degraded services, and adversarial inputs.

These constraints interconnect. State management enables graceful error handling through checkpointing. Observability depends on deterministic tool interfaces that produce consistent, traceable outputs. Security controls layer on top of explicit memory scopes that prevent cross-session contamination. The architecture succeeds when these constraints compose into systems that handle both expected operations and the inevitable failures production environments create.

…

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.

→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.

→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

The Hybrid AI Model Framework: Own What Matters, Rent What Doesn't

Nick Talwar — Fri, 20 Feb 2026 14:17:42 +0000

A two-layer architecture that treats enterprise data like a true asset

LLMs come with fundamental operational and security-related problems:
They hallucinate

They don't understand your specific business context without extensive prompt engineering

Once your data enters external systems, monitoring who accesses it becomes extremely difficult

A hybrid AI model helps to combat these issues. Instead of retrofitting security onto external systems, you build with two distinct layers from the start. You run a proprietary core trained on your fragmented internal data. You use generalized LLMs as utilities for non-sensitive tasks.

Different problems require different tools, and your most valuable data deserves more than API-level protection.

How a Hybrid Model Works

A hybrid setup operates with two distinct layers, each designed for different types of work.

The Core Proprietary Model handles everything that requires institutional knowledge or contains sensitive information. This layer gets trained or fine-tuned specifically on your internal data. The fragmented information sitting across databases, documentation systems, and tribal knowledge that actually runs your business. You deploy it privately (air-gapped, on-premises, or in tightly controlled infrastructure). You own it, govern it, version it.

The Generalized LLM Layer functions as a utility, similar to electricity or cloud compute. Use it for broad reasoning tasks, general drafting, summarization, anything that doesn't touch sensitive context.

Regulated customer data, competitive intelligence, and process IP stay in the proprietary core. General business tasks that could happen anywhere go to the utility layer.

Why This Works

It Eliminates Prompt Engineering Overhead

When your core model already understands domain-specific terminology, business rules, and institutional patterns, the prompt complexity drops. You stop spending cycles explaining your context in every interaction.
In my work with companies moving domain-specific work to fine-tuned internal models, I've seen prompt engineering overhead drop by 50-60%. The model knows product SKUs, understands compliance requirements, recognizes org structure. Questions that would require three paragraphs of context setup with ChatGPT work with a single sentence.

It Turns Fragmented Data Into an Asset

Fine-tuning a model on this distributed knowledge creates something actually useful. A unified intelligence layer that has ingested and made sense of information across silos. The model becomes a practical interface to knowledge that was previously locked away.

It Preserves Privacy Without Killing Usability

The user experience can look nearly identical to ChatGPT. What changes is what sits behind that interface.

The sensitive operations happen in infrastructure you control:

Customer PII never touches OpenAI's servers
Competitive analysis stays internal
Compliance teams can audit exactly what data moves where

Once data enters a big tech system, monitoring who accesses it becomes extremely difficult. Current privacy regulations create genuine liability when you can't track data lineage.

It Reduces Black-Box Provider Risk

The hybrid model limits exposure by keeping your most sensitive information completely separate from external systems. You're not trusting a third party to respect your anonymization or to maintain proper access controls. The data simply never leaves your environment.

When you own the core, you control the governance model, the retention policies, the access logs. When you rent utilities, you're only exposing information you'd be comfortable seeing anywhere.

When to Own, When to Rent

The decision framework comes down to three questions.

Does this task require institutional knowledge?

If the answer depends on understanding your specific processes, products, or customer context, it belongs in the proprietary core. If any competent professional could handle it with general knowledge, it can run through the utility layer.

What's the sensitivity level?

Regulated data, competitive intelligence, unreleased product details all stay internal. General business writing, research summaries, basic analysis can use external LLMs.

What's the cost of being wrong?

If a hallucination or data leak creates regulatory exposure, reputational damage, or competitive harm, you need the control that comes with ownership. If mistakes are cheap to catch and fix, utility models work fine.

Most enterprises find that 20-30% of their AI workload truly requires the proprietary core. The rest can run on general utilities, where you benefit from continuous model improvements without the maintenance burden.

Building for the Long Term

The hybrid approach requires upfront investment. You need to train or fine-tune models, set up private deployment infrastructure, and establish data pipelines. But the payoff is control over your most sensitive operations and ownership of the intelligence you develop.

The risks of sending enterprise data through external systems are very real: data leakage, compliance violations, and loss of competitive intelligence are real outcomes that enterprises can't afford. The hybrid model eliminates these exposures by keeping sensitive work on infrastructure you control.

Once you're operational, your most frequent queries run at marginal cost. Every interaction with your proprietary model generates data you can use to improve it. The intelligence stays with you.

…
_Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.
→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.
→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.
_

Stop Funding Stanford Grads. Start Funding These AI Founders Instead

Nick Talwar — Tue, 17 Feb 2026 15:01:04 +0000

Why bootstrapped operators with 18 months of AI-first operations are beating polished pitch decks

The $40 billion OpenAI round made headlines. The $13 billion Anthropic raise dominated tech news. Yet small AI businesses you haven’t heard of are generating revenue with two-person teams and unit economics that would make a Series B CFO jealous.

Most started bootstrapped, figured out AI integration through necessity, and built operational efficiency that funded companies spend a year trying to achieve. They’re not in your pitch meetings because they’re serving customers, not raising capital. That’s what makes them worth finding.

These bootstrapped operators are valuable because of the operational maturity they’ve already built. The profile is specific, the advantages are real, and the sourcing approach requires a different strategy than waiting for warm intros.

Signals That Actually Matter

Revenue at this scale tells you three things that matter more than credentials:

1) They found product-market fit without burning millions to discover it. Someone generating $50K MRR with a two-person team validated the problem, built something people pay for, and figured out unit economics that work. The hard part is done. Capital scales what’s proven rather than funding the search for what works.

2) They already have distribution figured out. TikTok channels with engaged audiences. Content engines that drive consistent traffic. Communities in their vertical that trust them. They have channels that already work and capital makes them more effective.

3) They built capital-efficient operations by necessity. Bootstrappers automate everything possible because they have to. That discipline compounds when you add capital.

Vertical Focus Creates Actual Moats

Here’s where the real defensibility lies. The bootstrapped operator already owns a specific niche with proprietary data accumulated through serving real customers.

Help them go deeper in that vertical rather than pushing them horizontal. A healthcare billing tool with 18 months of claims data and AI models trained on actual adjudication patterns has a moat. A generic “AI business assistant” has nothing but hope that OpenAI won’t crush them next Tuesday.

Horizontal AI products face commoditization risk from foundation model providers. OpenAI, Anthropic, Microsoft, and Google are actively building horizontal capabilities. They have more capital, more compute, and faster iteration cycles than any startup. Competing there is choosing to run uphill into machine gun fire. On the other hand, vertical AI with proprietary data and tight context wins because foundation models don’t have access to that specific corpus.

Where to Look

The best AI and Agent founders are building businesses and talking to customers.

This creates a sourcing problem for VCs used to founders seeking them out. You’ll need to go find these operators rather than waiting for them to apply. Look at who’s building in public on social media, who has small but profitable SaaS businesses, who’s actually shipping AI features that customers pay for.

The signal you’re looking for is revenue combined with operational maturity. Someone generating $30K MRR with a two-person team has already solved the hardest problems: finding customers, building something people pay for, and making the economics work. Capital helps them scale what’s proven, not figure out if it works.

When you find these operators, the pitch might look different than what you’re used to. They’re not asking you to believe in a vision. They’re showing you a working business and asking for help growing it. The unit economics are there. The customer feedback is real. The operational playbook exists. Your job becomes easier because you’re funding execution, not theory.

…

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.

→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.

→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

How To Build an AI or Agent Business With a Moat

Nick Talwar — Fri, 13 Feb 2026 14:53:16 +0000

Why sustainable AI advantage comes from what you capture, not what you rent

The conversation around AI and Agentic defensibility has become oddly ideological. One camp insists you must own your models and run everything locally to avoid vendor lock-in. The other argues that APIs are the only economically rational choice and worrying about moats is premature optimization.

In my personal opinion, both camps miss the point.

The real question isn’t whether you use APIs or local models. It’s whether you’re designing systems that generate defensible advantages regardless of whose intelligence you’re using.

Foundation model capabilities are commoditizing rapidly. What doesn’t commoditize is the proprietary data your product generates through deeply embedded user workflows.

The Dependency Problem Isn’t What You Think

When people worry about API dependency, they usually frame it as vendor lock-in or cost exposure. Those concerns are valid, but in my opinion secondary.

The actual problem is subtler. When you build on rented intelligence without capturing high-signal data from your users’ workflows, you’re constructing a business on sand. Your competitors can access the same models, implement similar features, and match your outputs. There’s nothing structural keeping users with you.

Model commoditization accelerates this dynamic. For example, GPT-4 was a leap forward when it launched. Within months, multiple providers offered comparable capabilities. Claude Sonnet raised the bar again. The cycle continues.

If your competitive advantage depends on having access to a “better” model, you’re playing a game with a six-month time horizon.

This is why horizontal products built on foundation models alone are vulnerable. They’ll get subsumed by the model providers themselves or by anyone else with API access. But AI in a vertical niche, tied to proprietary data that the big companies can’t crawl, is a different story. It gets better with tighter context over time, compounding advantages that generic horizontal tools can’t replicate.

Start With APIs and Design for Moat, Using this Architecture

Here’s where pragmatism matters. Starting with APIs makes sense for almost everyone.

The unit economics are clear. Google GCP, Microsoft Azure, and Amazon AWS achieve economies of scale you cannot replicate early on. They’ve optimized inference costs, distributed infrastructure globally, and handle reliability at a level that would consume your entire engineering budget to approximate. For validation, iteration, and early growth, APIs are the rational choice.

The strategic error isn’t using APIs. Rather it’s treating them as permanent infrastructure without building anything that compounds independently.

Think about what happens when you route user requests through an API, get responses, and return results. You’ve delivered value, but you haven’t captured anything proprietary. You have server logs and usage metrics, but those don’t differentiate you. Your competitors can implement the same flow tomorrow.

Now consider a different architecture:

User makes request.
System captures structured context about the request.
Routes to API.
Gets response.
User provides feedback (implicit or explicit).
System logs the feedback alongside the original context.

Over time, you accumulate a dataset mapping contexts to outcomes, refined by actual user behavior.

This is data exhaust. It’s high-signal, structured data generated as a byproduct of delivering value. And unlike API access, it’s yours.

Three Mechanisms That Create Distance

Defensibility in AI and Agents comes from three interlocking mechanisms. You need all three working together.

Workflow integration means your AI is embedded in the actual workflow, handling steps that used to require manual effort. This is what it means to build AI-first and AI-native operations. The more deeply integrated, the higher the switching cost. Users aren’t just losing access to a tool. They’re losing a system they’ve built their process around.

I’ve seen companies build AI features that users love but treat as optional supplements. Those products get replicated easily.

Compare that to systems where the AI handles core workflow steps and generates structured outputs that feed into downstream processes. Pulling that out means rebuilding workflows, not just swapping tools.

Data exhaust generation requires intentional design. Not all product usage produces useful data. You need to capture context, actions, and outcomes in a format that improves future model performance or product decisions.

The best data exhaust comes from correction loops. User generates output through your system, edits or refines it, approves final version. You now have ground truth for that context. Do this across thousands of users and you have a training corpus competitors can’t access.

Feedback loops turn data exhaust into compounding advantage. Every user interaction generates data. That data improves model performance, prompt engineering, or product features. Better outputs increase usage. More usage generates more data. The cycle accelerates.

This is where time horizon becomes a moat. A competitor can replicate your current product, but they start the flywheel from zero. You’re already three thousand iterations ahead. The gap widens with each cycle.

Building the Feedback Loop That Compounds

The most defensible AI and Agentic businesses design feedback loops from day one, even when using third-party APIs for inference.

Here’s what this looks like in practice. A user submits a request through your product. Before sending to the API, you capture structured context: user role, task type, key parameters. The API returns a response. You present it to the user. The user takes action: accepts, modifies, rejects. You log the outcome alongside the original context.

Over time, you build a proprietary dataset mapping contexts to outcomes, weighted by user behavior. This dataset has immediate value (you can fine-tune models, improve prompts, optimize for user preferences) and compounding value (it grows with usage and becomes harder to replicate as it scales).

This approach works identically whether you’re using Anthropic’s API or running Llama locally. The moat comes from the data layer, not the inference layer.

Companies that implement these loops see the impact quickly. Within 6 months, you’ll have accumulated enough signal to meaningfully outperform competitors starting from zero. The efficiency gains compound.

But you have to be willing to roll up your sleeves and actually instrument these systems properly, not just subscribe to ChatGPT and call yourself AI-native.

What This Means for Builders

The strategic landscape for AI and Agentic businesses is clarifying. Model access is commoditizing. Speed to market still matters, but not as much as designing for defensibility early.

The right approach is API-first for validation and growth, coupled with deliberate architecture for data moat. Don’t avoid APIs because of misplaced concerns about dependency. Use them pragmatically. But design your product so it generates and captures high-signal data from embedded workflows.

Your moat isn’t the model you use. It’s what you capture while using it.

…

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.

→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.

→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

Where AI Is Actually Paying Off in the Enterprise (and How It Leads to Agents)

Nick Talwar — Wed, 11 Feb 2026 18:39:14 +0000

How process understanding and business context separate real returns from expensive pilots

AI is already delivering returns in the enterprise. But the real question is where.

Developer productivity tools are working. Support chatbots handle tier-one issues. Content marketing operations, including global translations, have fallen dramatically in time and cost. These applications are deployed, measurable, and genuinely useful.

They’re also operating at the edges of what matters most to your business.

The next wave of AI value will come from applying Agentic AI to the core operational work that runs continuously: paying vendors, collecting receivables, fulfilling orders, managing inventory. Work that happens thousands of times per day and directly impacts margins, working capital, and customer experience.

The gap between current AI deployments and this next Agentic phase is simply operational context. Most enterprises are trying to deploy AI without giving it the two things it needs to work at scale: process understanding with proper observability feedback loops and business context.

Fix that, and the ROI stops being incremental.

Real Deployment, Shallow Impact

The Celonis Process Optimization Report surveyed 1,620 enterprise leaders across IT, Finance, Supply Chain, and Operations. Their findings are pretty clear: AI adoption is widespread, but depth is limited. Four in five organizations are using GenAI foundational models. Three in five have deployed chatbots for business users.

But dig into the use cases and it appears the most common applications cluster around two areas:

Boosting developer output
Automating tier-one support

Both are relatively easy to implement because they operate at the edges of core business operations. Furthermore, ROI from these activities is unlikely to shift the P&L in meaningful ways.

They help people work faster, but they don’t change how work flows through the organization.

AI Lacks the Map

There’s a reason most AI deployments stay shallow. Enterprises rush to implement tools and models without giving them the operational context needed to be useful beyond simple tasks.

Think about invoice processing. Looks straightforward: receive invoice, route for approval, pay vendor. Except that’s almost never how it actually works. Real invoice workflows involve multiple steps, exceptions, manual interventions, and cross-system handoffs. Some invoices need expedited approval. Others get blocked. Many require reconciliation across systems before payment can clear.

An AI without process understanding can’t navigate that. It sees “invoice received” and follows a linear script. When reality deviates (which it always does) the system stalls, creates noise, or makes mistakes that require human cleanup.

89% of leaders surveyed said it’s crucial that AI has context on how the business runs to be effectively deployed. And 58% are concerned their current processes may limit the value they can get from AI.

They’re right to be concerned. Now is the time to take it one step deeper, beyond linear SOPs fed into AI, into the age of Agentic AI.

Where the Real ROI Lives

The paper makes a straightforward claim: real enterprise value comes when AI is applied to core operational work that happens continuously, day in and day out. Activities like paying, collecting, shipping, fulfillment, procurement, etc.

The shift is from “helping people do work” to “improving how work moves.” That difference matters more than most organizations realize.

When AI assists a developer writing code, it creates local efficiency. When AI transitions to Agentic AI and optimizes an order-to-cash cycle that processes thousands of transactions daily, it creates systematic leverage. One affects individuals. The other affects margins, working capital, and customer experience at scale. We’ve seen this in our Board engagements where we dive deep on the business model and ladder-up where the AI gaps are blocking the company from true operational and profit leverage.

But to get there, AI needs two things most enterprises haven’t provided. And I see this time and time again, effectively blocking organizations ability to expand into real, durable value via Agentic AI.

The Missing Pieces

The two prerequisites are simple, but most organizations are missing both.

Process understanding means knowing how activities are sequenced across systems: what happens upstream, what happens downstream, what runs in parallel, whether tasks execute on time and in the right order. It’s a map of dependencies and a visual systems design model that can be taught to AI, in turn, so you can build Agents.

Business context means institutional knowledge codified into something AI can actually use. Things like business-specific rules, benchmarks, KPIs, etc. The logic that determines whether an order should be expedited, a vendor should be flagged, or an exception should escalate.

Without these, AI operates blind and you will never get to that Agent future everyone is yapping about. You can train the most sophisticated model on earth, but if it doesn’t understand that a partial shipment to a high-priority customer requires different handling than a routine order, it will automate the wrong thing.

Why This Becomes the Make-or-Break Layer

Unfortunately, I can’t sugarcoat this: AI deployments fail at the same rate whether you use cutting-edge models or last year’s version. The bottleneck is the lack of operational grounding.

Organizations need to understand how their processes actually run before they can expect AI, much less Agents, to improve them. That means visibility into what happens between systems, where work stalls, which exceptions occur most frequently, and how deviations from the ideal flow impact downstream outcomes. Often the best way to start is process-system diagrams (UML anyone?) that first local teams draw then expand to cross-group collaboration to see where bottlenecks are. You can even use AI to draw these and analyze them, even run simulations on how changes to stocks, flows, or multi-tier decisions affect overall COGS, operational spend, or resourcing. It’s powerful.

Process intelligence, on the other hand, creates a digital twin of operations. It connects data across systems, maps workflows as they actually execute, and makes that context accessible to AI and Agents. Instead of guessing how work should flow, Agents can see how it does flow and act accordingly.

The survey data backs this up. 81% of leaders say AI (really Agents) will be used to directly improve business processes over the next 12 months. Not to assist people in isolated tasks, but to change how core operations execute.

And when you ask Process Improvement and Operations leaders specifically, the conviction gets stronger. 89% say intelligent automation will unlock more value than anything else in the next five years. Not better analytics. Not incremental productivity gains. Automation grounded in operational understanding.

From Pilots to Process

There is a shift already happening from experimentation to integration. From asking “what can AI do?” to “where should AI act?”

The organizations moving with high impact, efficiently share a common pattern. They started with process visibility. They mapped their operations, identified where complexity creates friction, and targeted AI or Agents at the workflows that matter most to business outcomes. They gave AI the context it needs to operate safely and the process understanding it needs to deliver results.

The ones still stuck in pilot mode are usually missing one or both of those foundations.

What This Means for Enterprises

If you’re an executive evaluating AI or Agentic investments, the strategic question is really whether your organization understands its own operations well enough to make AI effective.

The easy wins are mostly claimed. Chatbots are handling tier-one support. Coding assistants are shipping with your IDE. Email copilots are writing draft responses and content operations with creative are using AI to create numerous drafts, distribute them, and translate them. These deliver value, but they won’t redefine your competitive position.

The next phase requires operational grounding. AI needs to understand how your business runs so you can graduate to a true Agentic posture. That means process visibility, business context, and the ability to act on both.

The survey data suggests we’re at an inflection point. AI is moving from peripheral productivity tools to core operational systems via Agentic technical architectures (the projects I am hands-on the most these days). The enterprises that succeed in the next phase will be the ones that solved for process understanding first.

Because AI without operational context is just expensive guesswork. And in operations that run thousands of times per day, guesswork doesn’t scale.

…

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.

→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.

→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

Are You a Decider or an Interpreter in the AI Agent Era?

Nick Talwar — Tue, 03 Feb 2026 21:40:39 +0000

From scattered pilots to strategic systems: why clear authority matters more than speed when AI Agents make everything possible.

Recently, a product team at a Series B company showed me three versions of the same feature. They’d been sitting in Figma for two weeks because nobody could decide which one to build.

The team was divided on which direction to go, with product leaning towards one design and engineering advocating for another. Leadership said “use your judgment” which meant nobody wanted to own the call. Meanwhile, the actual launch date slipped by a month.

This tension between product, engineering and leadership isn’t new. I’ve seen it at startups with 10 people and Fortune 500s with thousands.

Recently, a product team at a Series B company showed me three versions of the same feature. They’d been sitting in Figma for two weeks because nobody could decide which one to build.

This tension between product, engineering and leadership isn’t new. I’ve seen it at startups with 10 people and Fortune 500s with thousands.

Recently, a product team at a Series B company showed me three versions of the same feature. They’d been sitting in Figma for two weeks because nobody could decide which one to build.

This tension between product, engineering and leadership isn’t new. I’ve seen it at startups with 10 people and Fortune 500s with thousands.

What’s different now is that AI has made this dynamic significantly more expensive and exceedingly more apparent. When you can generate three versions of anything in an afternoon with AI, the bottleneck isn’t production anymore. It’s decision authority. And most organizations haven’t figured out who actually has it.

Two Roles Are Emerging Whether You’ve Assigned Them or Not

Here’s what I’ve learned across dozens of engagements: there are fundamentally two roles operating in every organization right now, regardless of what anyone’s title says.

Understanding which role you’re in, and which role your team members are in, determines whether AI or Agents make you faster or just creates more things to argue about.

The first I call “Deciders.” These are the people who define intent. They set constraints. They make the irreversible calls about priorities, acceptable trade-offs, and what should and should not be used.

A decider wouldn’t say “use your judgment.” Instead, they say things like “we’re optimizing for shipping speed this quarter” or “customer data privacy is non-negotiable, even if it limits what the product can do.”

The second role is “Interpreters.” These are the people who turn vagueness into work. When constraints aren’t set, they guess what leadership wants. They make judgment calls about priorities that should have been decided upstream. And they absorb the risk of getting it wrong.

Interpretation is often done by some of your most capable people. But it’s expensive because the interpreter is carrying decision-making risk without decision-making authority.

What Happens When Decisions Stay Murky

I recently advised a company that had an incredible team of engineers who could ship features in mere days, but unfortunately were stuck spending weeks in refinement cycles. Product leadership kept saying “make the product less buggy and more seamless” without defining what less buggy and more seamless actually meant for their Agents.

This left that engineering team trapped in interpretation mode, because the decision about acceptable quality thresholds had never been made. They’d build something, show it, get vague feedback from the business or customers, rebuild it, show it again. While these cycles were executed quickly, the product never actually moved forward and was stuck in a perpetual “never done” Agent demo posture.

Where Interpretation Hides in Your Organization

If you’re reading this and realizing your organization is too heavy on interpretation, here’s where to look. It shows up in predictable patterns:

The approval loop that won’t close. Work gets delivered, reviewed, revised, and re-reviewed. Not because there’s anything wrong with it, but because the original ask was ambiguous enough that “right” remains a moving target.
The over-explained decision. Someone writes three paragraphs justifying a straightforward choice. In this case they’re often compensating for missing constraints. They’re doing interpretive labor, building a case for why their guess aligns with unstated priorities, because the bounds weren’t set upfront.
The AI or Agent output that triggers debate instead of action. A team uses ChatGPT to generate campaign copy or Claude to draft a technical spec. Instead of picking one and moving forward, everyone weighs in on which version feels better. Nobody has clear authority to decide, so the output becomes another thing to interpret collectively.

These are clear signs that decision-making authority hasn’t been made explicit. And in an AI-accelerated environment, that ambiguity gets expensive fast.

What Deciding Actually Looks Like

So what does it mean to operate as a decider in an AI-driven organization?

It means setting constraints before work starts. You define what “done” looks like, what trade-offs are acceptable, and where the boundaries are. You’re not micromanaging execution, but you’re providing the frame that lets people move with confidence.

I like to call this the “AI Bookends” framework for decision-making for every workstream that is AI enabled or when you are building the product / engineering systems to ship AI or Agents themselves.

It also means being explicit about priorities. If everything is important, nothing is. AI can optimize for speed, quality, cost, or user experience, but it can’t determine which one matters most in a given context (or worse yet, it decides arbitrarily and the entire output is anchored on what it believes is the highest priority–”governance” anyone?) That’s your job as a decider.

The most effective deciders I’ve worked with don’t wait for questions to surface. They front-load the constraints. Before a project starts, they establish what’s non-negotiable. “This ships by the end of Q1, even if features get cut.” Or “We’re prioritizing technical foundation over user-facing polish this sprint.”

When those boundaries are clear upfront, teams don’t need to waste time and resources interpreting intent or second-guessing priorities. They can execute and use AI tools to explore options that actually fit within the parameters you’ve set.

When AI Exposes What Was Already Broken

In an AI-first organization, somebody has to own the call about what matters, what’s negotiable, and where the line is. If that authority isn’t explicit, then AI won’t actually make your teams any faster. They will just continue to spin their wheels until the problem becomes impossible to ignore.

The organizations that are already scaling AI and Agents effectively aren’t the ones with better tools or bigger budgets. They’re the ones where decision authority was already clear. AI just gives them leverage because their people can explore options confidently instead of guessing which direction leadership actually wants.

If your organization doesn’t work that way, AI or any number of Agents certainly won’t fix it. Rather it will expose it now more than ever.

So the question isn’t whether you’re ready for AI. It’s whether your organization will continue being stuck interpreting or move into a mode where decisions are actually made. AI just exposes and surfaces the lack of decision-making sophistication in your organization; get ahead of it before it results in a standstill or, worse yet, avoidable politics.

…

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts.

→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.

→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

The Agentic AI Maturity Gap: Orchestration + Observability + Auditability = Governance

Nick Talwar — Tue, 27 Jan 2026 15:58:07 +0000

From scattered pilots to strategic systems: the new competitive edge is AI that works together and is observable and auditable

Three years into the generative AI era, I've been watching a pattern repeat with clients across sectors.

The conversation usually starts the same way: they've got AI running somewhere in the org, often in a few places, showing some signs of Agentic behaviors. Customer service has a chatbot, product built a recommendation engine or narrative-driven LLM context flow, marketing runs campaigns through an LLM, and engineering automated some code reviews plus testing, etc.

Then the question: "How do we actually get value out of all this?"

This is the space between having Agentic AI and knowing what to do with it. Between feeling busy with AI projects and actually seeing business impact.

In 2026, research shows we're hitting an inflection point. Nearly 90% of companies report using AI in at least one business function, yet most still struggle to scale pilots or demonstrate clear ROI. The shift happening now looks less like a feature rollout and more like a redesign of operating models, governance structures, and risk management frameworks.

The winners this year won't be determined by who has the most AI. They'll be defined by who figured out orchestration, observability, and auditability.

The Real Problem Isn't Technology

Industry analysts project a surge from $7.8 billion today to over $52 billion by 2030 in the autonomous AI agent market, with predictions that 40% of enterprise applications will embed AI agents by the end of 2026.

But here's what those numbers miss: having Agents is different from orchestrating them.

I recently worked with a client that had 17 different AI implementations running across their business, from marketing automation to supply chain optimization to HR screening.

Each one worked fine in isolation. But then their product team tried to launch Agents that operations and the business couldn’t observe and audit, revealing existential risks and blindsides.. Nobody had actually designed these systems to work together because nobody thought about orchestration until it was too late.

Orchestration Means Strategic Integration, Not Just APIs

When people hear "orchestration," they often think integration layer. Connect the APIs, move some data around, call it done.

That's plumbing. Useful plumbing, but not orchestration.

Real orchestration means your AI systems understand context across domains. Think about specialized orchestrator models that can divide labor between different components, coordinating tools and language models to solve complex problems. It's the difference between having smart tools and having an intelligent system.

Here's an example. Let’s say a retail company wants to optimize inventory. They have demand forecasting AI in one corner, supply chain planning in another, pricing optimization somewhere else. All three are solid models. The issue is they all optimize for different things.

Orchestration can fix this by establishing a coordination layer. Rather than a central AI that replaces specialized models, this system would understand the relationships between their objectives. When demand forecasting suggests increasing inventory, the orchestration layer would check supply chain constraints and pricing implications before executing. Huge unlock for the organization and the business. Without it, there would be disconnects that affect customer delivery and the overall fulfillment process.

My prediction is that in 2026, enterprises will increasingly discover that the competitive frontier lies in managing specialized components effectively.

Governance is Observability as Competitive Advantage

Most executives still treat governance as the thing you do to stay compliant. The overhead that legal requires. The checkbox exercise before deployment. A key precursor or underlying aspect of governance with AI, though, is actually observability.

Can you trace AI and Agent actions to its original inputs and outputs at each interface or boundary so that you know what you are delivering across the long-tail of customer use cases is actually what you intended? If you can, you then have auditability, which in turn means you have governance.

That view is expensive and today with AI and Agents, very near-sighted or downright existentially risky. Before the risk was localized because the product and technology was deterministic–all code was WYSIWG mostly and was linear, not open-ended AI.

When Agentic AI started taking actions rather than just generating responses, governance stopped being about central review and became about designing systems that can operate responsibly at scale. The companies that figured this out early turned governance into observability and then quick feedback loops to gain the confidence to ship; in other words, speed that ships confidently.

Regulated industries are adopting auditable AI processes and model risk management as mandatory capabilities. The key elements include continuous monitoring, explainability requirements, version control, and transparent decision trails.

The firms treating these as features rather than constraints are moving faster than competitors still working through manual approval chains.

What Decision Velocity Actually Means

There's a concept gaining traction called "decision velocity" which refers to how quickly smaller decision trees and processes can be automated at scale. It's a useful lens for understanding what changes when orchestration and governance with observability work together.

Think about how decisions happen in most enterprises. Someone identifies an issue, gathers data, analyzes options, and escalates to whoever has authority. That person reviews context, makes a call, and communicates the decision. Implementation happens, and results get monitored.

Each step takes time. More importantly, each step involves coordination costs like finding the right person, explaining context, waiting for availability, and following up on execution.
AI and Agents change the equation when it can handle the entire loop, including execution and monitoring. But that only works if the Agent or AI understands the boundaries it operates within (governance) and can coordinate with other systems that need to know about the decision (orchestration).

I've seen companies achieve 5-7x improvements in certain decision cycles by getting this right. Not 10% better. Multiple times faster. The difference between responding to market changes in weeks versus days, or adjusting operations quarterly versus nearly continuously.

The Maturity Gap Shows Up in Measurement

Here's how you know if you have an orchestration problem: ask your teams what success looks like for their AI initiatives.

If everyone gives you different answers, you have a coordination gap. If nobody can connect their metrics across their peers to business outcomes, you have an orchestration gap. If people can't explain how their AI decisions affect other systems, you have a governance and auditability gap.

Research from MIT shows that organizations in early stages of AI maturity had financial performance below industry average, while those in advanced stages performed well above average. The difference is having the capabilities to use it strategically.

The maturity models all point to the same progression. You start with experimentation, where individual teams build individual solutions. That's fine for learning, but it doesn't scale.

The next stage involves getting systems to talk to each other, establishing shared data foundations, and building common platforms. This is where most enterprises are stuck as we kick off 2026.

Building for 2026 and Beyond

The companies positioning themselves well for this year are making specific choices.

They're prioritizing orchestration infrastructure over adding more point solutions. When evaluating new AI capabilities, they ask how it fits with existing systems before asking how good it is standalone.

They're treating governance frameworks as product decisions, not compliance exercises. Product takes governance and decomposes it into observability and auditability for the business, which is important for engineering and operations iterative cyles and “is the work” to deliver AI or Agentic AI predictably and accurately over time. Building observability into AI systems from the start. Designing for auditability. Creating clear accountability structures.

Leadership is shifting from centralized IT oversight to empowering line-of-business leaders to find and fund AI and Agent solutions that directly advance their goals. But that decentralization only works when there's strong orchestration and governance holding it together.

The most effective enterprise strategies begin with a foundational question: what data can we trust, and what do we need to fix before we automate decisions at scale. That's where orchestration and observability and auditably, leading to a true governance posture, intersect with execution.

The practical work involves several pieces: building coordination layers that let specialized AI and Agent systems work together, establishing governance frameworks that enable autonomous operation within clear boundaries, creating measurement systems that connect AI activity to business outcomes, and developing talent that understands both the technical and organizational aspects.

None of this is simple. But it's the work that separates companies using AI from companies transformed by it.

…
Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.
→ Follow him on LinkedIn to catch his latest thoughts.
→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.
→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

4 Strategies for Building an AI Startup That Survives the Coming Correction

Nick Talwar — Thu, 18 Dec 2025 15:35:01 +0000

Focus, patience, and precision separate enduring companies from temporary momentum.

Forbes reported that in August, nearly $1 trillion in market cap disappeared across big tech and AI-adjacent companies. Now more than 370 AI unicorns are standing on pretty shaky ground.

Startups built on momentum and marketing slides won’t make it through. The ones that last will be the ones built like systems. Grounded in revenue and resilience that still makes sense two quarters from now.

1. Build Moats Beyond the Model

The strongest companies will not win by having the best model because that edge does not last. We all know that technology is changing more quickly than we can even keep up with.

Survivors will create moats through distribution, enterprise integration, and access to proprietary or regulated data. They will build end-to-end workflows that customers cannot easily replace.

NVIDIA is a clear example. It did not just build chips, it created the infrastructure layer that the industry depends on. Vertical SaaS providers that deeply embed AI into their operations do the same. Once implemented, these systems are almost impossible to remove.

2. Manage Fragility in the Stack

Many AI startups remain overly dependent on others. They rely on NVIDIA for compute, OpenAI for APIs, and Microsoft or Google for distribution.

A supply shortage, a price hike, Google Apps deploying your startup as a feature, or a regulatory shift could put them out of business.

Companies that endure will design modular, model-agnostic architectures. They will build redundancy into their systems and prepare for the possibility that a key vendor may fail them. If one dependency can shut down your business, you are not building for resilience.

3. Prepare for Investor Scrutiny

The funding environment is already shifting. In Q1 2025, AI startups raised more than $80 billion. But that pace has slowed, and startups are now facing increased scrutiny.

Investors will demand ROI, transparent revenue models, compliance readiness, and governance that prevents waste and promotes a unified approach to AI adoption.

Founders must operate with the expectation that their next funding round will occur in a down market. That requires financial discipline, strong systems, and a clear plan for converting potential into performance. The bar has risen.

4. Think in Years, Not Quarters

AI is a general-purpose technology, much closer to electricity or the internet than to a product cycle.

Understand that the short term will be turbulent. Valuations will drop and pilots will fail. But the long-term trajectory looks a lot different. By 2030, AI will be deeply integrated across industries, driving trillions of dollars in economic value.

So which companies will remain standing? I believe the survivors will design platforms and workflows that embed into critical operations. They are building for the next decade, not the next fundraising pitch.

AI Will Outlast the “Bubble”

Some valuations will collapse, but AI will endure. And this isn’t always a bad thing. The correction will clear away what is unsustainable and reward what is built to last.

Yes, many startups will vanish. But the group that will survive will go on to reshape industries for decades to come.

. . .

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.
→ Follow him on LinkedIn to catch his latest thoughts.
→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.
→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.

Invisible Online? Here Is Why AI Doesn’t Cite Your Website

Nick Talwar — Mon, 15 Dec 2025 14:15:42 +0000

What decision-makers need to change today to build an ecosystem of authority that holds

For years, SEO was a mostly straightforward playbook with a few tricks sprinkled in.

Companies optimized their sites, adjusted metadata, and then, hopefully, climbed Google’s rankings. That approach rewarded those who knew how to tune for the algorithm.

The environment has changed. AI engines no longer stop at crawling your site.

They synthesize and summarize answers from across the web. It’s better for end users, but not the best for over three decades of online businesses.

If your strategy depends only on homepage optimization, you risk being invisible in this new discovery layer.

A high Google ranking is no longer a guarantee of relevance.

How AI Engines Process Information

AI engines process information in ways that diverge from traditional search. They provide direct summaries instead of long lists of links.

They gather information from multiple sources instead of relying on a single domain. They interpret natural questions written in everyday language rather than scanning for keywords.

Authority is now measured by whether your business appears across credible references.

Optimized metadata and backlinks still help, but they no longer define visibility on their own.

Why Your Footprint Beyond Your Site Matters

A well-designed site remains important, but it is only part of the story. AI engines look for signals of trust across the broader web.

They weigh reviews, partner-republished case studies, and expert mentions in third-party publications.

The difference this makes is measurable. I recently spoke with a B2B company that discovered that its product was being misrepresented in AI-generated responses because competitors had more citations across industry media.

After distributing corrected case studies and securing references in external publications, the company grew qualified leads by over 30% in a single month.

That result came from building credibility across multiple surfaces, not from additional homepage optimization.

The Risk of Staying Narrow

Competitors can now capture mindshare in AI-generated answers even when your site ranks well on Google.

Your hard-won search position becomes irrelevant if AI tools present competitor solutions as the authoritative answer to user queries.

Meanwhile, gaps in how your information appears across the web create opportunities for AI systems to generate incomplete or inaccurate descriptions of what you offer.

Without clear, accessible data about your company, AI tools fill the gaps with whatever information they find, or worse, with plausible-sounding fabrications.

Perhaps most critically, an overreliance on backlinks and keywords leaves your brand absent from the natural language conversations that AI engines prioritize.

These systems synthesize meaning from context, examples, and explanatory content that traditional SEO often ignores.

The result is a paradox: A company can rank well in Google yet remain invisible or misrepresented in AI results, which are increasingly where users begin their search.

What Matters for Business Leaders Today

Executives must rethink visibility. It cannot be anchored to the homepage. Rather, it is the product of a system that distributes credibility across multiple trusted channels.

When your organization is absent from that wider conversation, AI engines assume you are irrelevant.

It mirrors the infrastructure AI is built on, the concept of weighted trees and neural nets, where the most referenced items with the best explanations win in LLM recall.

This is not a campaign that runs for a quarter. It is infrastructure for trust in an environment where AI is rapidly becoming the front door to discovery.

. . .

3 Paths to Smarter Automation, Not Blind AI Adoption

Nick Talwar — Fri, 12 Dec 2025 14:00:33 +0000

A practical framework for leaders who want efficiency without sacrificing trust.

Too many leaders still assume automation means removing people. Plug in AI, step aside, and let the system take over.

AI does not replace judgment. It struggles with context, ethics, and trade-offs. It even struggles with basic arithmetic (do not ask an LLM to help you with dosage or scaling-up the measurements in a recipe, it always gets it wrong).

When people are cut out entirely, the system looks efficient until it fails.

The real opportunity is balance. Automation should deliver efficiency while maintaining trust and accountability.

Where Over-Automation Breaks Down

AI performs well with speed and pattern recognition, but breaks down in ambiguous or high-variance situations.

A self-driving car can handle a long stretch of highway, yet stumbles at an urban intersection in poor weather.

A generative model can draft a contract quickly, but it may miss a clause that shifts risk onto your business.

Fully manual systems create their own limits. A finance team reviewing every invoice by hand will always struggle to keep up with scale.

The real question is how to design human and machine collaboration that matches the work being done.

Model 1: Human in the Loop

This model puts AI in charge of the process, with people responsible for approval, correction, or override.

It is best for environments where errors carry heavy consequences, such as healthcare, aviation, or content moderation.

Its strength is in trust and accountability. A human can decide when flagged content is satire rather than harmful speech.

Its weakness is speed. Every required approval slows the system, which becomes costly in high-volume settings.

Model 2: AI in the Loop

Here, people remain in charge while AI supports them with analysis and recommendations. This works well in fields like treatment planning, education, or financial advising.

The strength lies in amplification. A physician can weigh treatment outcomes across similar patients. A teacher can identify students most at risk and intervene earlier.

The weakness is bias. Experts may trust flawed recommendations too readily. The human decision remains, but the risk grows if the AI is over-relied upon.

Model 3: Human on the Loop

This model lets AI run autonomously, with humans supervising and stepping in only when needed. It fits best in trading, logistics, or drone operations, where scale and speed matter most.

The benefit is efficiency at scale. A logistics system can reroute shipments instantly when disruption hits, far faster than a human team.

The risk is complacency. If people trust the system too much, they may fail to intervene when oversight is most critical.

Choosing the Right Model

The right choice depends on the complexity of the task, the stakes involved, and the maturity of the technology.

High-stakes, high-complexity work requires human-in-the-loop systems. As systems prove reliability, organizations can shift toward human-on-the-loop approaches.

The mistake many companies make is skipping that progression and handing over too much control too early.

Oversight should evolve with trust. It should not vanish before the system has earned it.

Practical Applications for Leaders

Automation design is a systems decision, not a feature to tick off or a technology to deploy for appearances.

The right model reduces operational drag, prevents wasted cycles, and builds infrastructure that holds steady when stress-tested.

Leaders who treat automation as a structural choice position their organizations for durability, not just short-term efficiency gains.

Executives need to start by identifying the areas where human judgment is non-negotiable. In those spaces, guardrails must remain.

From there, oversight should be designed to evolve over time, moving from close involvement to lighter supervision as trust in the system grows.

This creates a pathway where automation can scale responsibly without exposing the business to unnecessary risk.

The organizations that succeed will be the ones that match automation to context, avoid brittle shortcuts, and build systems that earn confidence from stakeholders.

Resilience, not speed, is what sustains growth.

The Bottom Line

AI by itself is brittle. Human-driven systems by themselves cannot scale. The strongest organizations combine the two, adopting models that fit their level of complexity and maturity.

. . .

Nick Talwar is a CTO, ex-Microsoft, and a hands-on AI engineer who supports executives in navigating AI adoption. He shares insights on AI-first strategies to drive bottom-line impact.

→ Follow him on LinkedIn to catch his latest thoughts._
→ Subscribe to his free Substack for in-depth articles delivered straight to your inbox.
→ Watch the live session to see how leaders in highly regulated industries leverage AI to cut manual work and drive ROI.