Task Context vs Shared Context: The Mental Model That Makes AI Product Teams Actually Scale

AI did not introduce the need for context. It exposed how little of it most teams have.

Right now, “context engineering” is having its moment. People talk about RAG, long context windows, tool calling, and standards like the Model Context Protocol. (Model Context Protocol) Those are real advances. But they skip the harder question that determines whether any of it works: what does good context look like in the first place, for humans and for AI?

If you want a clear lens, steal this one: task context versus shared context. Luca Rossi frames it crisply in his Refactoring essay, and it maps cleanly to how high-performing teams have always operated. (Refactoring.fm)

The contractor test

A simple test: imagine the engineer building your next feature is not on your team. They are a contractor you just onboarded, someone smart and capable, but unfamiliar with your norms. That is not a hypothetical anymore. It is increasingly what an AI agent is.

If you hand them a ticket with “Build onboarding flow v2,” plus a Figma link and a couple requirements, they can produce something. But will it be something you can ship?

They will immediately need answers to questions you probably do not write down:

Do you require tests? Which kinds? What is your definition of “done”? How do you instrument features? Do you have naming conventions? Are feature flags mandatory? How do you handle error states? What is acceptable latency? Which security checks are non-negotiable?

This is where the split matters.

Task context is the “what”

Task context is the job-specific payload. The feature spec. The user story. The acceptance criteria. The UI designs. The edge cases. The constraints that are true this time.

Task context changes constantly. It is supposed to. It is the volatile layer. If you are building a pricing experiment this week and an identity integration next week, task context should look completely different.

When people complain that AI “needs more context,” they often mean task context. That is valid, up to a point. But if you keep stuffing more into the prompt, you are treating the symptom.

Shared context is the “how”

Shared context is everything your team should not have to restate.

It is your working agreements and operating standards. It is the invisible scaffolding that lets an engineer succeed without a manager hovering. It is also the difference between “a prototype that passes a demo” and “a change that fits the system.”

In strong orgs, shared context lives in artifacts you can point to: engineering handbooks, golden paths, paved roads, templates, code review standards, test strategy, observability norms, security posture.

Google’s public engineering practices around code review are a good example of shared context expressed as a standard. The point is not perfection. The point is that code health improves over time because reviewers share an explicit bar. (Google GitHub) Microsoft’s Engineering Fundamentals Playbook is another example, a broad, explicit catalog of how teams work across delivery, quality, and collaboration. (Microsoft GitHub)

AI makes the absence of shared context painful, because AI will happily generate plausible output that violates your unwritten rules.

The north star: shrink the “what,” grow the “how”

Here is the counterintuitive strategy that actually scales: continuously shrink task context and grow shared context.(Refactoring.fm)

Shrinking task context does not mean writing vague tickets. It means you stop using tickets to carry institutional memory. You stop writing “make sure you add feature flags” or “remember to add metrics” or “please follow naming conventions” in every single prompt, PR, or story. Those are not task instructions. They are operating norms.

If you have to remind people to “write tests,” you do not have a testing practice. You have a testing suggestion.

And here is the uncomfortable truth: if you have to remind your AI agent to write tests every time, you do not have AI context engineering. You have prompt heroics.

GitHub’s own Copilot guidance implicitly points in this direction. Copilot is useful for generating tests and repetitive code, but the team still has to be in charge of standards and review. (GitHub Docs) Scaling AI safely is less about better clever prompts, and more about making the “how” unmissable.

The new industry signal: shared context is becoming machine-readable

The most important shift of the last year is not that models got bigger. It is that teams are starting to package shared context in a way agents can reliably consume.

AGENTS.md is an emerging open format that is effectively a README for coding agents. It exists for one reason: projects need a predictable place to put “how we work here.” (Agents) OpenAI’s Codex documentation goes further and describes how these instruction files can be layered from global guidance to repo guidance to directory-specific overrides. (OpenAI Developers) This is not a small UX detail. This is the shape of the next generation engineering handbook, one that can be applied automatically at the point of code generation.

On the “tools and data” side, MCP is doing something similar for external context: standardizing how AI apps connect to data sources and tools, so the agent can fetch the right facts instead of hallucinating. (Model Context Protocol)

Put those two together and you get a clean architecture:

Task context answers what you are building right now.
Shared context encodes how you build anything here.
Tool context provides the live facts and actions needed to execute.

Most teams are over-invested in the first and under-invested in the second.

When to use task context, and when it becomes a trap

Use task context aggressively when the work is ambiguous, novel, or decision-heavy. If the work requires tradeoffs, you want the tradeoffs visible. If the work impacts customers, you want explicit success metrics and failure modes. If there are non-obvious constraints, you want them written.

But task context becomes a trap when it is used to compensate for missing standards. If your tickets keep carrying the same reminders, your system is telling you something: the “how” is not shared.

There is also a failure mode that looks like maturity but is not: bloated specs that try to precompute every decision. Humans ignore them. Agents drown in them. A task spec should be a crisp description of intent and constraints, not an attempt to smuggle an entire engineering culture into a single document.

When to use shared context, and why most teams underfund it

Shared context should cover the recurring decisions that cause rework. Every time you see a repeat failure, that is a shared-context gap trying to get your attention.

In practice, shared context should make these things boring:

Testing expectations and commands, including what “good” looks like for unit, integration, and end-to-end coverage.
Observability norms, including logs, metrics, traces, and what gets instrumented by default.
Release discipline, including feature flags, rollout strategy, and how you handle canaries.
Code review standards, including what reviewers must enforce and what they should let slide. (Google GitHub)
Security defaults, including how secrets are handled, how dependencies are introduced, and what checks must pass.

If that sounds like a lot, good. High-performing orgs make this explicit because it reduces cognitive load. It also makes onboarding faster, whether the newcomer is a human engineer or an agent.

How to combine them without creating a mess

The clean combination pattern is simple: task context should point to shared context, not repeat it.

In human terms: “Build the new onboarding flow. Follow our standard release checklist and instrumentation guide.”

In agent terms: your Codex or agent instruction chain carries the shared context, while the prompt carries only what is unique to this task. That is exactly the layering model described for AGENTS.md style guidance. (OpenAI Developers)

This is where teams get leverage. Once shared context is dependable, task prompts can get shorter without quality collapsing. You are not lowering the bar. You are embedding it.

When to avoid both

There are two moments to deliberately avoid context.

The first is exploration. If you are brainstorming product directions, do not force shared delivery standards into the conversation. You want divergent thinking.

The second is when you are trying to diagnose a failure and you do not yet know if it is a task problem or a shared problem. If you immediately patch the output, you will miss the chance to fix the input that caused it.

This is the move most teams fail to make: treat failures as context bugs, not human bugs.

The feedback loop is the real context engine

Rossi’s point that resonates most is that good context engineering is a feedback loop. When something turns out wrong, the question is rarely “why was the output bad?” The real question is “what input allowed this to happen?” (Refactoring.fm)

In mature orgs, that loop looks a lot like incident response, but applied to product delivery:

If a PR shipped without adequate tests, you can fix the PR. But you should also update the shared checklist and the agent guidance, so it does not happen again.
If a feature launched without metrics, you can patch instrumentation. But you should also fix the default template, the definition of done, and the shared playbook.
If AI-generated code repeatedly violates conventions, you can keep correcting it. Or you can encode conventions once, in the place the agent always reads.

That is why formats like AGENTS.md matter. They give you a stable place to put the “how,” then evolve it as you learn. (Agents)

The opinionated takeaway

If you want AI to amplify your team, stop treating context as a prompt problem. Treat it as an operating system problem.

Task context is fuel. Shared context is the engine. Tools and live data are the sensors. If you only pour more fuel into a weak engine, you do not go faster. You just make more smoke.

The teams that win with AI will not be the teams with the most clever prompts. They will be the teams that make “how we build” explicit, enforceable, and continuously improved, until both humans and agents can ship high-quality work with minimal hand-holding.

Your Agent Does Not Need More Prompt. It Needs Memory.

Most teams try to fix weak agents by rewriting prompts. That is usually the wrong move.

The real issue is that the agent has no durable memory model. It can answer the current turn, but it cannot reliably carry forward user preferences, prior decisions, task context, or the small facts that make an interaction feel intelligent instead of stateless. Microsoft Agent Framework already gives you the extension points to solve this. By default, it uses in-memory chat history or service-managed history depending on the underlying provider, and it separates conversation history from richer context injection through ChatHistoryProvider and AIContextProvider. That separation is exactly what you want if you are serious about building agents that behave like products rather than demos. (Microsoft Learn)

As of February 2026, Microsoft Agent Framework is in Release Candidate for both .NET and Python, with the API surface described as stable on the road to GA. Microsoft also positions it as the successor to Semantic Kernel and AutoGen for agent development, which makes it the right place to invest if you are building new agent systems on the Microsoft stack. (Microsoft for Developers)

The important architectural move is this: do not treat “memory” as one blob. In Microsoft Agent Framework, short-term conversational recall belongs in ChatHistoryProvider. Durable user and workflow memory belongs in an AIContextProviderbacked by your own memory service. External knowledge belongs in retrieval, not memory. The framework pipeline reflects that design. On each run, history is loaded first, then context providers add messages, tools, or instructions, then the LLM executes, and afterward both history and context providers are notified so they can store new information. (Microsoft Learn)

That means a good memory design has three layers.

First, keep recent turns available so the model can follow the conversation naturally. Second, maintain a durable memory store that saves distilled facts such as user preferences, entities, project state, or decisions. Third, use retrieval for external documents and domain knowledge. Microsoft’s RAG support already follows this pattern through TextSearchProvider and Semantic Kernel vector store integrations, which is why you should resist the temptation to dump everything into “memory.” Retrieval is for knowledge. Memory is for continuity. (Microsoft Learn)

The cleanest way to add a memory service in .NET is to create a custom AIContextProvider. Microsoft’s docs explicitly describe AIContextProvider as the extension point for memory and context enrichment, and they show a memory-service pattern that loads relevant memories before invocation and stores new memories after invocation. They also make an important point that many teams miss: the same provider instance is reused across sessions, so session-specific state must not live on the provider object itself. It should live in the AgentSession, typically through ProviderSessionState<TState>. (Microsoft Learn)

Here is the pattern I would use.

using System.Text;
using Microsoft.Agents.AI;
public interface IMemoryService
{
    Task<string> CreateMemoryContainerAsync(CancellationToken cancellationToken = default);
    Task<IReadOnlyList<MemoryFact>> SearchAsync(
        string memoryContainerId,
        string query,
        int top = 5,
        CancellationToken cancellationToken = default);
    Task StoreAsync(
        string memoryContainerId,
        IEnumerable<ChatMessage> messages,
        CancellationToken cancellationToken = default);
}
public sealed record MemoryFact(string Text, double Score);
internal sealed class DurableMemoryProvider : AIContextProvider
{
    private readonly IMemoryService _memoryService;
    private readonly ProviderSessionState<State> _sessionState;
    public DurableMemoryProvider(IMemoryService memoryService)
        : base(null, null)
    {
        _memoryService = memoryService;
        _sessionState = new ProviderSessionState<State>(
            _ => new State(),
            stateKey: nameof(DurableMemoryProvider));
    }
    public override string StateKey => _sessionState.StateKey;
    protected override async ValueTask<AIContext> ProvideAIContextAsync(
        InvokingContext context,
        CancellationToken cancellationToken = default)
    {
        var state = _sessionState.GetOrInitializeState(context.Session);
        if (string.IsNullOrWhiteSpace(state.MemoryContainerId))
        {
            return new AIContext();
        }
        var userInput = string.Join(
            "\n",
            context.AIContext.Messages?
                .Where(m => m.GetAgentRequestMessageSourceType() == AgentRequestMessageSourceType.External)
                .Select(m => m.Text) ?? []);
        if (string.IsNullOrWhiteSpace(userInput))
        {
            return new AIContext();
        }
        var memories = await _memoryService.SearchAsync(
            state.MemoryContainerId,
            userInput,
            top: 5,
            cancellationToken);
        if (memories.Count == 0)
        {
            return new AIContext();
        }
        var memoryBlock = new StringBuilder();
        memoryBlock.AppendLine("Relevant durable memory for this conversation:");
        foreach (var memory in memories)
        {
            memoryBlock.AppendLine($"- {memory.Text}");
        }
        memoryBlock.AppendLine("Use this only when relevant. Do not invent details.");
        return new AIContext
        {
            Messages =
            [
                new ChatMessage(ChatRole.System, memoryBlock.ToString())
            ]
        };
    }
    protected override async ValueTask StoreAIContextAsync(
        InvokedContext context,
        CancellationToken cancellationToken = default)
    {
        var state = _sessionState.GetOrInitializeState(context.Session);
        if (string.IsNullOrWhiteSpace(state.MemoryContainerId))
        {
            state.MemoryContainerId = await _memoryService.CreateMemoryContainerAsync(cancellationToken);
            _sessionState.SaveState(context.Session, state);
        }
        var newMessages = context.RequestMessages.Concat(context.ResponseMessages ?? []);
        await _memoryService.StoreAsync(state.MemoryContainerId!, newMessages, cancellationToken);
    }
    private sealed class State
    {
        public string? MemoryContainerId { get; set; }
    }
}

This pattern does two things that matter. Before the model runs, it searches durable memory using only the new external input, not the full accumulated prompt. After the model runs, it stores the latest exchange back into the memory service. That lines up with the framework’s documented ProvideAIContextAsync and StoreAIContextAsync lifecycle, and it keeps the memory container ID in session state where it belongs. (Microsoft Learn)

Then wire it into your agent the way the framework intends:

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")
    ?? throw new InvalidOperationException("Set AZURE_OPENAI_ENDPOINT");
var deploymentName = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME")
    ?? "gpt-4o-mini";
IMemoryService memoryService = new YourMemoryServiceImplementation();
AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new AzureCliCredential())
    .GetChatClient(deploymentName)
    .AsAIAgent(new ChatClientAgentOptions
    {
        ChatOptions = new() { Instructions = "You are a helpful assistant." },
        ChatHistoryProvider = new InMemoryChatHistoryProvider(),
        AIContextProviders =
        [
            new DurableMemoryProvider(memoryService)
        ]
    });
AgentSession session = await agent.CreateSessionAsync();
Console.WriteLine(await agent.RunAsync("My preferred reporting format is concise.", session));
Console.WriteLine(await agent.RunAsync("How should you format future updates for me?", session));

That registration model is straight out of the framework’s current design: one history provider, plus a list of context providers for memory, RAG, or dynamic instructions. (Microsoft Learn)

There is one more design choice that separates solid implementations from messy ones. Do not store raw transcripts forever and call that memory. A real memory service should distill turns into durable facts. “User prefers concise updates.” “Client uses Workday.” “Case escalated on March 12.” “Do not recommend option B because legal rejected it.” Your StoreAsync method should extract candidate facts, score them, deduplicate them, and set an expiration policy where appropriate. The framework gives you the hook points, but the product quality comes from what you choose to remember.

You also need to manage context growth. Microsoft’s compaction guidance is useful here. If you use CompactionProvider, be deliberate about where you register it. When registered through ChatClientAgentOptions, synthetic summaries can become part of persisted history. If you only want to compact the in-flight context window while preserving the original stored history, register compaction on the chat client builder with UseAIContextProviders(...) instead. That is a subtle detail, but it matters once your agent starts running real workloads instead of toy chats. (Microsoft Learn)

For production hosting, this pattern becomes even more powerful when paired with durable execution. Microsoft’s Azure Functions integration for Agent Framework supports durable thread management and persistent state for long-running, reliable workloads, with automatic endpoints and state handling. That is the right direction if your memory-backed agent is part of a business workflow rather than a single-turn assistant. (Microsoft Learn)

The broader lesson is simple. Memory should not be a prompt hack. It should be an architectural layer.

Microsoft Agent Framework is opinionated in the right way here. It gives you a dedicated history mechanism, a dedicated context mechanism, and a clean place to plug in your own memory service. Use those primitives as intended and you get an agent that remembers the right things, forgets the wrong things, and behaves consistently across sessions. Ignore them and you end up with an expensive autocomplete loop pretending to be an agent.

Defining Product Value: Stop Treating Products Like Projects

Most leadership teams say they are building “product value,” then immediately measure it like a finance exercise. ROI. LTV. Payback period. Those numbers matter, but they are also the fastest way to undervalue the most important products you will ever build. The uncomfortable truth is that many of the products that changed industries looked irrational on a spreadsheet in year one. They were not irrational. They were investments that created new compounding loops: better distribution, better data, stronger ecosystems, lower marginal cost to serve, and tighter control of the customer relationship.

Amazon has been blunt about this philosophy for decades: prioritize long-term market leadership over short-term profitability and measure investments analytically over time. (Corporate Investor Relations) That mindset is not a motivational poster. It is a valuation model. When you treat product as an investment vehicle, you stop asking “what is the ROI of this feature?” and start asking “what new asset does this create, and what future options does it unlock?”

ROI and LTV are necessary, but they are not sufficient

ROI and LTV are great at valuing direct monetization. They are weak at valuing strategic leverage.

They struggle with:

  • Platform effects where value accrues to the ecosystem first, and only later to you.
  • Capability-building where the product’s “profit” is speed, quality, and resilience across everything else you do.
  • Trust and risk reduction where the return shows up as avoided loss, regulatory confidence, and sales velocity.
  • Option value where the real payoff is the ability to launch the next thing faster and cheaper.

If you only use ROI and LTV, you will systematically underfund the products that create compounding advantage and overfund the products that create short-term optics.

A better question: What kind of value are we creating?

Here is the shift that changes everything. Instead of asking, “How much value does this product have?”, ask, “What typeof value is this product designed to create?” In my experience, modern product value shows up in five forms that compound when you get them right.

1) Ecosystem value: when your product becomes the market’s default surface area

Apple’s App Store is a masterclass in valuing the ecosystem, not just the transaction. Apple highlights that the App Store ecosystem facilitated roughly $1.3 trillion in billings and sales in 2024. (Apple) Whether you agree with every policy choice, the valuation insight is undeniable: the product’s value is not only Apple’s direct revenue. It is the gravitational pull that attracts developers, anchors users, and reinforces the platform.

If you try to measure a platform strictly by ROI in the early innings, you will miss the point. Platforms often look “expensive” until they become unavoidable.

2) Capability value: when the product is a factory for future products

AWS is the canonical example of a capability investment that turned into a new business category. It began as internal infrastructure discipline and APIs that made Amazon faster and more reliable, then became a product that changed how software is built. (Corporate Investor Relations) The early value was operational leverage. The later value was market creation.

You can see a modern version of this pattern inside software teams adopting AI-assisted development. Controlled studies and research report meaningful productivity gains with tools like GitHub Copilot, including faster task completion in experimental settings. (Microsoft) The point is not “AI will save us.” The point is that a tool can be a product investment when it upgrades throughput, developer experience, and time-to-market across everything you ship.

3) Data value: when learning becomes the moat

Netflix has long treated personalization as a value engine because it converts data into better decisions about discovery and engagement. External analyses describe that recommendations drive a large share of viewing activity, reinforcing retention and content discovery. (New America) You do not measure that with a single-feature ROI. You measure it as a learning system that compounds: every interaction makes the product smarter, and every improvement makes the next interaction more valuable.

In AI-first product design, this becomes even more direct. Your differentiation is rarely the model. Your differentiation is the feedback loop: the quality of your signals, the speed of iteration, and the discipline of your evaluation.

4) Distribution value: when the product lowers customer acquisition friction

Some products are valuable because they become your “front door,” even if they are not the primary revenue engine. Salesforce has invested heavily in enablement and ecosystem building, framing the broader “Salesforce Economy” as massive job and revenue creation beyond Salesforce itself. (Trailhead) You can debate methodologies, but the strategic idea is powerful: if your ecosystem grows faster than your competitors’ ecosystems, you win distribution, talent gravity, and partner momentum.

For CTOs and CPOs, distribution value often hides inside developer platforms, integrations, workflow surfaces, and anything that makes your product the easiest place to start.

5) Trust value: when the product accelerates sales and reduces existential risk

Trust is not soft. It is a growth lever and a risk hedge. Products that embed privacy, security, and compliance create value by shortening procurement cycles, reducing churn from security concerns, and preventing catastrophic downside. Many teams only “feel” this value when something goes wrong. That is too late.

If you want to value trust properly, treat it like an asset that increases conversion rates and protects cash flows under stress. It is not just cost avoidance. It is sales velocity and renewal confidence.

The valuation move that changes portfolio decisions: treat product like a set of real options

Here is a practical way to think about it without turning your operating rhythm into a finance seminar. A real option is the right, not the obligation, to make a future move. Great products create options: launch new modules, expand into new segments, partner with an ecosystem, shift pricing models, automate service delivery, or apply AI safely because your data and governance are ready.

That is why “feature ROI” often feels like a trap. The value is frequently not the feature. The value is the new option it creates.

Amazon’s long-term posture makes this explicit: invest for market leadership, measure what works, cut what does not, and double down on what compounds. (Corporate Investor Relations) That is real-option thinking in plain language.

Where AI changes the game for product value

AI does not just add features. It changes the unit economics of building, shipping, and operating products.

When you combine engineering management, product management, and software craftsmanship with AI, you can:

  • Reduce the cost of iteration, which increases experimentation volume and learning speed.
  • Improve quality through better testing, review support, and faster refactoring cycles, if you apply discipline.
  • Turn workflows into intelligent systems, where value compounds through feedback loops rather than static releases.

But AI also punishes sloppy teams. If you do not invest in evaluation, safety, and engineering fundamentals, you will ship confident nonsense at scale. That destroys trust value faster than it creates novelty.

The Point…

If you only value products by ROI and LTV, you will keep funding what looks safe and starving what creates durable advantage. The products that matter most often create value sideways first: ecosystems, capabilities, data loops, distribution, and trust. The cash shows up later, and when it does, it tends to compound.

The leadership move is to name the value you are building, instrument it like you mean it, and allocate investment like a portfolio manager, not a project sponsor. That is how you stop shipping features and start building assets.

If you want, I can turn this into a tighter LinkedIn version with one core story arc and two supporting examples, while keeping the same POV and evidence.

How to Add a Secure JavaScript Execution Tool to Microsoft Agent Framework

There is a recurring moment in agent design where a team realizes the model does not just need to reason. It needs to compute. It needs to transform JSON, run a formula, post-process extracted fields, normalize dates, build a dynamic object, or apply domain logic that is simply easier to express in JavaScript than in prompt text.

That is where most teams make a dangerous move. They reach for eval, Function, or Node’s vm module and tell themselves it is “sandboxed enough.”

It is not.

Node’s own documentation is explicit that node:vm is not a security mechanism and should not be used to run untrusted code. Worker threads are also not the right boundary for hostile code because they are designed for parallelism and can share memory. At the same time, Microsoft Agent Framework is built to let agents call external tools through function tools, so the clean pattern is not “run JavaScript inside the agent host.” The clean pattern is “make JavaScript execution a remote tool with a hardened execution boundary.” (Node.js)

That is the architecture this post covers:

  • Microsoft Agent Framework in .NET
  • A custom function tool exposed to the agent
  • A tRPC call from the tool to a separate Node.js execution service
  • Execution inside a locked-down isolate, not vm
  • Explicit whitelisting of namespaces and packages
  • Validation, time limits, memory limits, and auditable policy controls

The key design principle is simple: treat JavaScript execution as a privileged capability, not a convenience API.

The architecture

At a high level, the flow looks like this:

  1. The agent decides it needs computation.
  2. Microsoft Agent Framework calls a function tool.
  3. The function tool sends a request over HTTP to a tRPC endpoint in Node.js.
  4. The Node service validates the request with Zod.
  5. The Node service creates an isolated execution environment.
  6. Only approved globals and wrapped package facades are injected.
  7. The code runs with strict limits for time, memory, and output shape.
  8. The result is returned to the agent as tool output.

Microsoft Agent Framework supports function tools as first-class extensions to an agent, and tRPC gives you a type-safe RPC layer with input and output validation. That combination is ideal here because the .NET side stays thin and deterministic, while the execution policy lives in one place on the Node side. (Microsoft Learn)

First principle: “secure eval” is really “isolated execution”

It is important to be direct here. There is no magic secureEval() in Node.js. If you are executing model-authored or user-authored JavaScript, the safest practical pattern is:

  • out-of-process execution boundary
  • fresh isolate per run or per tenant pool
  • no ambient filesystem or network access
  • no raw require
  • whitelisted host-provided capabilities only
  • timeouts, memory ceilings, and payload size limits
  • container and OS-level restrictions around the service

Why not use node:vm? Because the Node docs explicitly say not to use it as a security boundary. Why not just use worker threads? Because workers are concurrency primitives, not isolation primitives. A better starting point for JavaScript isolation in Node is isolated-vm, which exposes V8 isolates and is designed for running code in fresh environments with no default Node runtime capabilities. Node’s permission model can also further restrict the Node process itself. (Node.js)

The important nuance is this: even isolated-vm should be one layer, not the only layer. The strongest production posture is to run the execution service in its own locked-down container or workload boundary and assume defense in depth.

Tool contract design

Do not let the model send arbitrary source code and a free-form module list with no governance. Give it a constrained contract.

A good request shape looks like this:

import { z } from "zod";
export const ExecuteJsInput = z.object({
  code: z.string().max(10_000),
  input: z.unknown().optional(),
  allowedNamespaces: z.array(z.string()).default([]),
  allowedPackages: z.array(z.string()).default([]),
  expectedResultSchema: z
    .object({
      type: z.enum(["json", "string", "number", "boolean", "array", "object"]),
    })
    .optional(),
  timeoutMs: z.number().int().min(50).max(3000).default(1000),
});

This matters for two reasons.

First, tRPC is designed around typed procedures, and Zod-driven validation makes the boundary explicit. Second, you now have a place to enforce policy before any code gets near an isolate. (trpc.io)

The Microsoft Agent Framework side

On the .NET side, the tool should be boring. That is the goal.

Microsoft Agent Framework lets you expose custom logic through function tools, including by creating an AIFunction from a C# method. The agent does not need to know how tRPC works. It just needs a tool description that makes the capability understandable to the model. (Microsoft Learn)

A simplified example:

using System.ComponentModel;
using System.Net.Http.Json;
public class JavaScriptExecutionTool
{
    private readonly HttpClient _httpClient;
    public JavaScriptExecutionTool(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }
    [Description("Executes tightly sandboxed JavaScript for deterministic data transformation and calculation.")]
    public async Task<string> ExecuteSandboxedJavaScript(
        [Description("The JavaScript source to execute. Must return a serializable result.")] string code,
        [Description("Optional JSON input payload for the script.")] string? inputJson = null,
        [Description("Approved namespaces the script may access.")] string[]? allowedNamespaces = null,
        [Description("Approved package facades the script may access.")] string[]? allowedPackages = null)
    {
        var request = new
        {
            code,
            input = string.IsNullOrWhiteSpace(inputJson) ? null : System.Text.Json.JsonSerializer.Deserialize<object>(inputJson),
            allowedNamespaces = allowedNamespaces ?? Array.Empty<string>(),
            allowedPackages = allowedPackages ?? Array.Empty<string>(),
            timeoutMs = 1000
        };
        var response = await _httpClient.PostAsJsonAsync("/trpc/js.execute", request);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

Then you register it as a function tool with your agent. The architectural point is more important than the exact setup syntax: the agent host never evaluates code locally. It delegates execution to the hardened service. (Microsoft Learn)

The tRPC boundary

tRPC is a strong fit because it gives you typed procedures, validation, and a clean contract between the .NET caller and Node service. Even though .NET is not consuming generated TypeScript types directly, the Node service still benefits from strict schemas and a maintainable procedure surface. (trpc.io)

Example router:

import { initTRPC } from "@trpc/server";
import { z } from "zod";
import { ExecuteJsInput } from "./schemas";
import { runSandboxedScript } from "./sandbox";
const t = initTRPC.create();
export const appRouter = t.router({
  js: t.router({
    execute: t.procedure
      .input(ExecuteJsInput)
      .mutation(async ({ input, ctx }) => {
        return await runSandboxedScript(input, ctx.policyStore);
      }),
  }),
});
export type AppRouter = typeof appRouter;

This is where you can also add authentication, tenant context, rate limiting, audit metadata, and policy lookup.

The secure execution service

This is the heart of the design.

The mistake many teams make is trying to whitelist modules by exposing require. Do not do that. If you expose require, you are recreating Node inside the sandbox and dramatically expanding the attack surface.

Instead, preload and wrap approved capabilities in the host, then inject only those facades into the isolate.

That means your whitelist is not “the sandbox may import lodash.” It is “the sandbox may access a safe facade called packages.lodash that exposes only get, pick, and omit.”

That is a much better boundary.

Example policy registry

type NamespaceFactory = () => Record<string, unknown>;
type PackageFactory = () => Record<string, unknown>;
const namespaceRegistry: Record<string, NamespaceFactory> = {
  math: () => ({
    round: Math.round,
    floor: Math.floor,
    ceil: Math.ceil,
    max: Math.max,
    min: Math.min,
  }),
  dates: () => ({
    nowIso: () => new Date().toISOString(),
  }),
};
const packageRegistry: Record<string, PackageFactory> = {
  lodash: () => {
    const { get, pick, omit } = require("lodash");
    return { get, pick, omit };
  },
  decimal: () => {
    const Decimal = require("decimal.js");
    return { Decimal };
  },
};

Notice what is missing: no arbitrary imports, no filesystem, no fetch, no process access, no environment access.

Example isolate runner

import ivm from "isolated-vm";
import { ExecuteJsInput } from "./schemas";
export async function runSandboxedScript(
  request: z.infer<typeof ExecuteJsInput>,
  policyStore: PolicyStore
) {
  const policy = await policyStore.resolve({
    namespaces: request.allowedNamespaces,
    packages: request.allowedPackages,
  });
  const isolate = new ivm.Isolate({ memoryLimit: 64 });
  const context = await isolate.createContext();
  const jail = context.global;
  await jail.set("global", jail.derefInto());
  const safeNamespaces = Object.fromEntries(
    policy.namespaces.map((name) => [name, namespaceRegistry[name]!()])
  );
  const safePackages = Object.fromEntries(
    policy.packages.map((name) => [name, packageRegistry[name]!()])
  );
  await jail.set("input", new ivm.ExternalCopy(request.input ?? null).copyInto());
  await jail.set("namespaces", new ivm.ExternalCopy(safeNamespaces).copyInto());
  await jail.set("packages", new ivm.ExternalCopy(safePackages).copyInto());
  const wrapped = `
    "use strict";
    (async function () {
      const console = undefined;
      const process = undefined;
      const require = undefined;
      const module = undefined;
      const exports = undefined;
      const Buffer = undefined;
      const setTimeout = undefined;
      const setInterval = undefined;
      const userFn = async ({ input, namespaces, packages }) => {
        ${request.code}
      };
      return await userFn({ input, namespaces, packages });
    })()
  `;
  const script = await isolate.compileScript(wrapped);
  try {
    const result = await script.run(context, { timeout: request.timeoutMs });
    const copied = await new ivm.Reference(result).copy();
    return {
      ok: true,
      result: copied,
    };
  } catch (error) {
    return {
      ok: false,
      error: sanitizeError(error),
    };
  } finally {
    isolate.dispose();
  }
}

This is intentionally opinionated.

  • The sandbox gets input
  • The sandbox gets namespaces
  • The sandbox gets packages
  • The sandbox does not get Node
  • The sandbox does not get require
  • The sandbox does not get the environment

That is the right posture.

The isolated-vm project describes these isolates as separate JavaScript environments free of the extra capabilities that Node normally exposes. That is why it is a better primitive here than vm. (GitHub)

How whitelisting should really work

A lot of teams hear “whitelist packages” and think they should allow date-fns or lodash directly. That is still too coarse.

You want three policy levels.

1. Namespace whitelist

These are internal capability groups you define, such as:

  • math
  • dates
  • currency
  • tax
  • normalizers

These are ideal for domain logic because they let you present stable semantic surfaces to the model.

2. Package facade whitelist

This is not raw NPM package access. It is a curated wrapper over a package.

Example:

const packageRegistry = {
  dateFns: () => {
    const { addDays, formatISO, parseISO } = require("date-fns");
    return { addDays, formatISO, parseISO };
  },
};

3. Tenant or tool policy whitelist

Even if a package exists in the registry, a given agent or tenant may not be allowed to use it.

That means final access should be the intersection of:

  • globally supported capabilities
  • tenant policy
  • current agent policy
  • current tool invocation request

That keeps the model from escalating its own power simply by naming more packages.

What “most secure method” means in practice

Here is the honest version.

If the code is untrusted, the strongest production pattern is not “just use a safer JavaScript library.” The strongest pattern is:

  • dedicated Node execution service
  • running in a separate process or container from the agent host
  • Node permission model enabled where possible
  • no filesystem permission unless explicitly required
  • no network permission unless explicitly required
  • no child process permission
  • no raw module loading
  • isolate-based execution inside the service
  • per-request timeout
  • per-request memory cap
  • rate limiting and audit logging
  • kill-and-recycle strategy for suspicious runs

Node’s permission model is now stable and is specifically intended to restrict access to resources during execution. That makes it a useful outer control around the execution worker process. (Node.js)

So the recommendation is:

Do not run JavaScript evaluation in the Microsoft Agent Framework process. Run it in a separate hardened execution service, and inside that service use an isolate with only host-injected safe facades.

Prompting the agent correctly

One subtle mistake is giving the model too much freedom in how it uses the tool. Your tool description should bias toward deterministic use cases.

Good use cases:

  • schema normalization
  • mathematical calculations
  • JSON reshaping
  • derived field generation
  • deterministic validation helpers
  • short business-rule transforms

Bad use cases:

  • arbitrary web requests
  • importing unknown libraries
  • long-running workflows
  • anything requiring secret access
  • anything that should really be a reviewed backend feature

You want the tool to feel more like “dynamic formula execution” than “tiny remote code runner.”

Observability and governance

Once you add this capability, you need a paper trail.

Log:

  • agent name
  • conversation or run id
  • caller identity
  • code hash
  • requested namespaces
  • requested packages
  • approved namespaces
  • approved packages
  • execution duration
  • memory tier
  • success or failure
  • sanitized error output

Do not log secrets in payloads. Do log enough to reconstruct who ran what and under which policy.

This matters because the risk is no longer just technical. It is operational. A dynamic execution tool without auditability becomes impossible to govern at scale.

Where this pattern is worth it

This pattern is especially valuable when building agents that need deterministic computation without shipping a new backend endpoint for every micro-use-case.

Examples:

  • tax calculation helpers
  • document extraction post-processing
  • migration mapping rules
  • payroll normalization
  • dynamic scoring or threshold logic
  • transforming AI output into strict structured shapes

In all of those cases, JavaScript is the execution language, but policy is the product.

Final opinion

The wrong way to add JavaScript to an agent is to think of it as a convenience feature.

The right way is to think of it as a controlled runtime.

Microsoft Agent Framework gives you the right extension point through function tools. tRPC gives you a clean typed boundary. Node can host the execution service. But the part that separates a toy from a production design is this: never let the model execute inside your primary trust boundary, and never equate “sandboxed” with “safe” unless you can explain the exact layers doing the isolation. (Microsoft Learn)

That is the architecture I use.

The Steinberger Threshold

Most leaders are asking the wrong question about AI.

They ask whether their teams are using it. They ask which model to standardize on. They ask whether agents are ready for production. They ask how quickly they can drive adoption.

That is all downstream. The real question is simpler and far more revealing: who on your team can actually direct AI, and who is starting to be directed by it? That is the divide I keep seeing in product and engineering organizations.

Some people use AI to expand their judgment. Others use it to avoid judgment. Some get faster while staying in control. Others get busy, impressed, and strangely passive. On the surface, both groups can look productive. Both can generate output. Both can show progress.

Only one of them is actually becoming more valuable. That is what is being referred to by some as The Steinberger Threshold.

I am borrowing the phrase from recent discussion around Peter Steinberger, but what matters is not the label. What matters is the shift it names. Steinberger is worth paying attention to because he has lived through multiple eras of software building, from deep technical craftsmanship to AI-native execution. The lesson embedded in his public writing and interviews is clear: the advantage is no longer just in doing the work yourself. The advantage is in framing the work, shaping the environment, inspecting the result, and deciding what happens next.

That is not prompt engineering. That is modern judgment. And that is why this matters more than another generic debate about AI productivity.

We are moving into a world where the cost of execution is falling fast. Agents can increasingly read codebases, edit files, run tests, summarize options, and handle meaningful chunks of delivery work. As that happens, the bottleneck shifts.

When execution gets cheaper, judgment gets more expensive.

That changes who stands out. It changes who scales. It changes who should lead.

The people who thrive in this environment will not be the ones who simply know how to use AI. That bar is dropping quickly. The people who thrive will be the ones who can define intent clearly, give the agent enough structure to move fast, and still know when the machine is wrong, shallow, overconfident, or drifting off mission.

That is the threshold. Below it, people let the agent set the pace, shape the work, and quietly narrow their thinking. Above it, people use the agent as leverage while keeping hold of direction, standards, and accountability.

This is not a tooling issue. It is a leadership issue.

The biggest mistake I see companies making is assuming AI adoption and AI capability are the same thing. They are not. Giving people access to powerful models tells you almost nothing about whether they can use them well. In fact, broad access can hide the problem for a while. Everyone suddenly looks more productive. More documents appear. More prototypes show up. More code gets written. More tickets move.

But velocity is a bad metric when the system can generate convincing motion on demand.

That is where executives get trapped. They see acceleration and assume capability has risen with it. Sometimes it has. Sometimes they are just watching the organization become more dependent on machine output without improving its ability to set direction or judge quality.

That is the real risk.

The person below the Steinberger Threshold is not necessarily junior. They are not necessarily non-technical. They are simply no longer fully in command once AI enters the loop. They delegate too early. They trust polished output too quickly. They confuse completeness with correctness. They let the system define the path instead of using the system to execute against a path they have defined.

The person above the threshold behaves very differently. They treat the agent like fast, tireless, sometimes brilliant labor. They know what outcome they want. They know where ambiguity is useful and where it is dangerous. They know when to tighten the frame. They know what needs review and what can be safely skimmed. Most importantly, they stay accountable for the result.

That last point matters more than people admit.

The best agent operators are usually not the ones writing the fanciest prompts. They are the ones with the clearest standards. They know what good looks like. They can spot weak reasoning. They can tell when the agent is optimizing for fluency instead of truth, or speed instead of soundness. They do not need to inspect every line, but they know exactly which lines matter.

This is why I think the rise of agents will reshuffle status inside product and engineering teams more than most people expect.

Some managers will struggle because they were already operating through abstraction without enough contact with the actual work. AI will expose that quickly. If you cannot define success in a way that a machine can execute against and a human can validate, your authority gets thinner.

Some engineers will struggle too, especially those whose identity is tied too tightly to personal output. AI does not care about your attachment to hand-crafted implementation if someone else can steer the machine to a better result faster.

And some people in the middle of the organization will rise quickly. They may not have the biggest titles. But they have taste. They can decompose messy problems. They can write clear acceptance criteria. They can create structure where others create noise. They can tell the difference between a useful first pass and a dangerous hallucination. In an agentic world, those people become force multipliers.

You can already see the outlines of this shift in the market. Companies are starting to act as though part of every team’s job is now translating work into something machines can execute. Whether you look at AI-first operating models, agentic coding environments, or the emerging idea of software factories, the pattern is the same: the bottleneck is moving away from raw execution and toward the ability to define, direct, and verify execution.

That is the Steinberger Threshold in practice.

So how do you figure out who has crossed it? Not with training completion rates. Not with prompt libraries. Not with AI badges. You run a scout mission.

By that I mean a real piece of work with enough ambiguity that judgment matters, enough structure that success can be observed, and enough consequence that the quality of direction shows up clearly. It should be something an agent can materially accelerate, but not something so trivial that the agent can stumble into a passable answer without supervision.

A good scout mission is not theater. It is a bounded business problem that exposes how someone thinks in an agentic environment.

Give them a real bug with messy symptoms. Give them a workflow that needs redesign. Give them a thin internal tool to build. Give them a reporting process full of edge cases. Then watch what they do.

Do they sharpen the objective before they delegate? Do they define acceptance criteria? Do they improve the environment with better tests, clearer documentation, or stronger context? Do they review the critical path or only the polished summary? Do they notice drift? Do they challenge the output? Can they explain why the result should be trusted?

Most importantly, when the agent gets stronger, do they become more decisive or more passive? That is the question.

Because that is what separates someone who is using AI as leverage from someone who is slowly handing over their agency to it.

My view is simple. The companies that win with AI will not be the ones with the most licenses, the biggest model budget, or the loudest transformation language. They will be the ones that identify who can actually operate above the Steinberger Threshold, then redesign teams, workflows, and leadership expectations around those people.

Because once agents become part of the execution layer, judgment becomes the scarce asset.

And scarce assets end up running the system.

AI is not killing the PM role. It is being forced to grow up.

Agile changed the choreography of delivery, but it did not fundamentally change the cast. We kept the same job titles, the same swim lanes, and mostly the same power dynamics. AI is different because it collapses the distance between intent and execution. Engineers can prototype in hours. Designers can ship interactive flows without waiting for front-end availability. Researchers can summarize themes across hundreds of interviews in minutes. Documentation is no longer a sacred artifact because it can be generated on demand.

When everyone can “do the thing” faster, the old product manager value proposition gets exposed.

Not because PMs are unnecessary, but because too many PMs have been operating as human middleware. In an AI-enabled team, middleware becomes friction.

Product management is becoming the bottleneck again, but not for the reason people think

Andrew Ng has been blunt about what he is seeing: engineering velocity is exploding, while product decision velocity is not keeping up. He has cited teams floating extreme staffing ratios like “1 PM to 0.5 engineers,” precisely because the constraint is no longer “can we build it,” it is “what should we build next, and why.” (The Washington Post)

That lands uncomfortably because it cuts through a decade of agile mythology. We convinced ourselves that tighter cycles and better rituals would make decisions faster. In practice, many teams just shipped smaller batches of indecision.

AI does not fix that. AI amplifies it.

If your org cannot make crisp calls on tradeoffs, positioning, risk, and sequencing, then AI turns your product into a slot machine. Lots of output, unpredictable outcomes.

The real shift: from writing requirements to engineering decisions

In AI-enabled teams, the PM’s center of gravity moves away from “capturing what we know” and toward “creating the conditions to learn faster than competitors.”

That is why the most valuable PMs are becoming:

  1. System designers of feedback loops.
    If engineers can build ten prototypes this week, your job is to ensure you can get ten rounds of real feedback this week. Not opinions from internal stakeholders. Not a survey that takes a month. Actual behavioral signal, usability signal, and commercial signal. Ng’s point about product work becoming the bottleneck is basically a warning that many teams still run discovery like it is 2015. (LinkedIn)
  2. Narrative owners who reduce ambiguity.
    AI makes it cheap to create options. It does not make it cheap to align a company. The PM’s job is to create a shared narrative that makes tradeoffs obvious. What are we optimizing for this quarter. What risks are acceptable. What customer segment wins. What we are explicitly not doing.
  3. Outcome executives, not ticket shepherds.
    There is a reason the “PM as project manager” instinct feels so suffocating in modern teams. Dr. Bart Jaworski’s micromanagement critique hits because it describes a PM role that has quietly metastasized into dependency chasing and task decomposition, which is exactly the work AI will commoditize first. (LinkedIn)

Here is the uncomfortable truth: if your calendar is full of status checks, you are not leading product. You are compensating for a system that does not trust itself.

AI pushes PMs into an accountability gap, and you either own it or get sidelined

A lot of leaders are responding to AI by demanding “builder ratios,” fewer coordinators, more doers. You can see the cultural momentum in how companies publicly talk about AI expectations. Shopify’s CEO memo, widely circulated, framed AI usage as a baseline expectation and pushed teams to try AI before asking for more headcount. (Business Insider) Duolingo’s “AI-first” shift, including changes to how work is staffed, is another example of leadership trying to rewire the org around automation and leverage. (The Verge)

The implication is not “PMs are dead.”

The implication is: the org has less patience for roles that cannot directly accelerate learning and outcomes.

This is why the PM job splits into two archetypes in AI-enabled environments:

  • The “product operator” PM who runs ceremonies, writes tickets, and translates between functions. AI eats a meaningful chunk of this, and orgs will push it into tooling, into the team, or into program management.
  • The “product strategist and experiment leader” PM who sets direction, clarifies the bet, instruments the system, and drives rapid iteration with tight customer loops. This PM becomes more valuable, not less.

Most PMs want to believe they are the second archetype. Their calendars often reveal they are the first.

“But everyone can prototype now.” Exactly. That is why the PM must level up.

The PM in an AI-enabled team cannot be purely a non-technical coordinator. You do not need to be a production engineer, but you must be able to move at the speed of prototypes. Otherwise, you become the pacing item that Andrew Ng is warning about.

This is where “vibe coding” becomes a useful cultural signal. Andrej Karpathy’s framing captured what many teams are living: people can increasingly build by intent, using natural language to drive code generation. (on X)

If you are a PM and your superpower is writing a spec that takes two weeks to socialize, you will lose credibility in a world where a teammate can generate three working prototypes before your PRD is approved.

So what replaces the PRD as the PM’s leverage?

A tighter operating system for decisions.

What the best PMs are doing differently right now

They are not micromanaging delivery. They are not disappearing into strategy decks either. They are building a product learning engine that can keep pace with AI-accelerated execution.

Practically, that looks like this:

  • They treat prototypes as questions, not solutions. Each prototype exists to answer one uncertainty: desirability, usability, feasibility, viability, compliance risk, adoption friction. If your prototype is not tied to a question, it is just expensive entertainment.
  • They shorten the loop from build to signal. They ship behind flags, use concierge tests, run internal dogfooding with instrumentation, and put customers in front of flows weekly, not quarterly.
  • They operationalize customer truth. AI can summarize interviews, but it cannot decide what matters. The PM owns the mechanism that converts messy qualitative input into clear product calls.
  • They create decision hygiene. In high-velocity teams, the cost of a bad decision is not the decision. The cost is the cascade. PMs need lightweight decision records, explicit tradeoffs, and crisp “reversibility” framing so teams can move fast without becoming reckless.
  • They make the team safer to move quickly. That includes guardrails for privacy, security, and compliance, especially when AI features touch regulated data. The PM is often the person who ensures “fast” does not become “fragile.”

The paradox: PMs must stop being the bottleneck by doing more “product,” not more “process”

If product management is becoming the bottleneck, the fix is not hiring more PMs to write more documents. It is upgrading the PM role into a higher-leverage function.

This is where the comparison to agile is useful. Agile gave us faster cycles, but many companies never built true empowerment. They created rituals around a command-and-control core.

AI will punish that model.

Because AI does not just increase speed. It increases optionality. And optionality without empowered decision-making becomes chaos.

So the question is not “what is the PM’s role in an AI-enabled team.”

The question is: can your PM function produce clarity, priority, and validated learning as fast as your engineers can produce code?

Security is not “tech debt” or “engineering work.” It is product work.

If you have ever watched a product manager and an engineering lead debate whether a security improvement “counts” as roadmap progress, you have seen a symptom of a deeper problem. The argument is rarely about the work itself. It is about ownership, incentives, and an outdated mental model where “product” means features and “security” means delay.

That mindset is legacy. It made sense when software shipped quarterly, lived behind corporate networks, and only a small slice of customers ever evaluated your security posture. It does not make sense in a world where your product is continuously delivered, deployed across a messy supply chain, and sold into procurement processes that treat trust as a first-class requirement.

Progressive teams stop debating whether security belongs on the roadmap. They design roadmaps where security is already inside the user journey, the platform, and the operating model.

Srajan Gupta captures the heart of the issue through the lens of security companies: security products are judged under pressure, not during polished demos, and traditional product thinking often fails when the stakes are highest. (srajangupta.substack.com) That observation translates cleanly outside “security products.” Your SaaS, your mobile app, your internal platform, and your API marketplace are also judged on their worst day: a breach, an outage, a bad permission model, or a compromised dependency.

When that day hits, nobody cares that your Q3 roadmap was feature-rich.

Why security keeps losing the roadmap fight

Security loses because most organizations treat it like a backlog category instead of a product property. In planning, features get narratives and champions. Security gets tickets and guilt.

That structural mismatch creates the usual failure mode: security is framed as “paying down debt,” and debt is framed as “optional until it hurts.” Then it hurts, loudly, and you pay in panic, churn, and deal friction.

There is a better framing: security is not a set of tasks you sprinkle in. It is a set of constraints and promises your product makes to users.

AWS has been telling the industry this for years, in plain language. The security pillar of the Well-Architected Framework is not a checklist you run after you build the workload. It is guidance for design, delivery, and maintenance. (AWS Documentation) That is product language, not just engineering language.

The same theme shows up in government and standards bodies: NIST’s Secure Software Development Framework (SSDF) is explicitly about integrating secure practices into your SDLC, because most SDLC models do not address security in enough detail by default. (NIST Computer Security Resource Center) In other words, if you do not deliberately wire security into the way you plan and build, it will not happen consistently.

And the market has moved from “best effort” to “secure by design.” CISA’s Secure by Design work pushes the idea that software makers should prioritize customer security as a core business requirement, not an add-on feature. (CISA)

This is the shift: security is now part of product legitimacy.

The fastest way to go “upstream” is to put security into the journey, not the sprint

When teams talk about “shifting left,” they often mean scanning earlier. That is necessary, but it is not sufficient.

Upstream security means you model risk at the same time you model value.

Security needs to show up in the same artifacts where product decisions are made: discovery notes, PRDs, wireframes, acceptance criteria, launch checklists, and go-to-market narratives. If the only place security appears is a Jira epic called “Hardening,” you have already lost.

Microsoft’s Security Development Lifecycle (SDL) is a canonical example of codifying security across phases such as requirements, design, implementation, verification, and release. (Microsoft) The big idea is not that Microsoft has more security engineers. The big idea is that the system forces teams to make security decisions early and repeatedly, not just at the end.

Here is what “security in the journey” actually looks like in modern products:

It shows up when the user first signs up and you decide whether “passwordless” is a convenience feature or a security control that changes your fraud model. It shows up when you design roles and permissions and realize that most breaches are not “hackers,” they are over-privileged accounts and confusing authorization paths. It shows up when you design audit logs and decide whether customers can prove what happened, not just guess. It shows up when you build integrations and realize your API is now part of your customer’s attack surface.

Those are product decisions. They shape usability, conversion, retention, and revenue.

Stop treating security as a tradeoff against speed. Make it a force multiplier.

The best security investment is the one that reduces cognitive load for teams and customers.

GitHub’s Dependabot security updates are a great example of this philosophy: instead of asking every team to manually track vulnerable dependencies, the platform can automatically surface alerts and create pull requests to remediate. (GitHub Docs) This is security as workflow design. It reduces toil and time-to-fix without turning every sprint into a negotiation.

Supply chain security is another domain where “security as product” is winning. SLSA (Supply-chain Levels for Software Artifacts) is framed as incrementally adoptable levels that help prevent tampering and improve integrity across the chain. (SLSA) The power here is not the framework itself. The power is the product thinking behind it: define maturity levels, make progress measurable, and give teams a path that does not require perfection on day one.

This is how you escape the tech debt trap. You build paved roads.

Security becomes a platform capability: automated scanning, dependency hygiene, secure defaults, policy-as-code, hardened templates, and straightforward patterns that teams can adopt without heroics. When you do this well, product teams ship faster because they stop reinventing security decisions for every feature.

Product management’s job is to make security legible

If you want security to be prioritized, you need to express it in the language the roadmap already rewards: user impact, business outcomes, and measurable risk reduction.

That does not mean fearmongering. It means clarity.

Security work often suffers because it is described at the wrong altitude. “Improve encryption” is not a product statement. “Protect sensitive documents at rest and in transit across download, share, and integration flows” is a product statement.

Progressive product leaders translate security into customer value and operational readiness. They treat a secure experience as part of the feature itself, not as a shadow backlog.

Frameworks like OWASP SAMM exist precisely to help organizations build a risk-driven, measurable security program across the lifecycle. (OWASP) You do not need to adopt every model wholesale, but you do need the discipline they represent: security maturity should be intentional and visible.

AI makes the “security is product” argument unavoidable

AI is accelerating shipping velocity, which is great until it accelerates vulnerability throughput too.

More importantly, AI changes your threat model. You are no longer only protecting data stores and endpoints. You are protecting prompts, tools, and agent workflows. You are protecting against misuse, not just bugs.

NIST has started extending secure development practices specifically for AI model development, which is a signal that security leaders are no longer treating AI as “just another feature.” (NIST Computer Security Resource Center) The organizations that win here will not bolt on governance after an incident. They will design AI capabilities with explicit guardrails, logging, and abuse cases from day one, and they will make those guardrails part of the user experience.

If your AI roadmap is all magic and no threat modeling, you are building a future incident response exercise.

What progressive teams do differently

They do not “prioritize security more.” They remove the conditions that cause security to be deprioritized.

They align product and engineering on a few non-negotiables:

  • They define secure defaults as part of the product contract, and they treat deviations as explicit product decisions, not implementation details.
  • They include abuse cases and threat modeling in discovery, so the “how could this be misused?” conversation happens before code exists.
  • They bake security acceptance criteria into Definition of Done, so security is not something you remember, it is something you ship.
  • They invest in platform capabilities that make secure behavior the path of least resistance, following the same automation logic that tools like Dependabot represent. (GitHub Docs)
  • They talk about security in customer language, supported by recognized frameworks like SSDF, SDL, and Secure by Design, because trust has become part of how products are bought. (NIST Computer Security Resource Center)

Notice what is missing: the weekly fight about whether a security epic “steals” from feature delivery. That fight disappears when security is not a competing backlog. It is the way you build features.

The real competitive advantage is trust that compounds

In many markets, feature differentiation is fleeting. Trust is sticky. Teams that treat security as a product property win in three compounding ways.

They reduce existential risk because they are not gambling on luck. They ship faster because secure patterns and automation eliminate repeated decisions. And they sell faster because customers increasingly demand proof, not promises, and “secure by design” is becoming table stakes. (CISA)

If you want a modern roadmap philosophy, adopt this one: security is not what you do after you ship. Security is what makes shipping sustainable.

And once you internalize that, the question stops being “when do we schedule security?” The question becomes “how do we design the product so security is simply how it works?”

From Using AI to Running AI: The Next Skill Gap

The biggest mistake leaders are making right now is framing the next era as a contest between humans and AI.

That is not what is happening inside high-performing teams. The real separation is already showing up somewhere else: between people who use AI and people who orchestrate it.

AI users get output. AI orchestrators get outcomes.

AI users treat the model like a clever intern. They prompt, they paste, they polish. Their ceiling is the quality of a single interaction.

AI orchestrators design a system where multiple interactions, tools, guardrails, and humans combine into a reliable workflow. They turn “a helpful answer” into “a completed job.” They stop thinking in prompts and start thinking in production.

You can see the industry converging on this. Microsoft is explicitly pushing “multi-agent orchestration” in Copilot Studio, including patterns for handoffs, governance, and monitoring because real work is rarely single-step. (Microsoft) OpenAI’s own guidance leans into the same idea: routines, handoffs, and coordination as the core primitives for building systems you can control and test. (OpenAI Developers) Anthropic draws a clean distinction between workflows that are orchestrated through predefined paths and agents that dynamically use tools, then spends most of its energy on what makes those systems effective in practice. (Anthropic) LangGraph has effectively positioned itself as the “agent runtime” layer for state, control flow, and debugging, which is exactly what orchestration needs when you leave toy demos behind. (LangChain)

This is why “AI literacy” is quickly becoming table stakes and then getting commoditized. Everyone will learn to prompt. Everyone will learn to generate code, slides, summaries, and drafts. That advantage collapses fast.

Orchestration does not collapse fast because it is not a trick. It is an operating model.

What an AI orchestrator actually does

Orchestration is not “use more agents.” Orchestration is the discipline of turning messy work into a repeatable machine without pretending the work is clean.

An orchestrator:

  • Breaks work into steps that can be delegated and verified, not just executed.
  • Connects AI to the real world through tools, systems, and data.
  • Designs handoffs, failure modes, and escalation paths as first-class product features. (Microsoft Learn)
  • Builds observability so you can debug behavior, not just admire outcomes. (Microsoft Learn)
  • Treats evaluation as a release gate, not a vibe check. (Anthropic)

That is why orchestration is showing up everywhere as “multi-agent,” “tool use,” and “workflows vs agents.” It is the same idea wearing different vendor hoodies. (Anthropic)

The uncomfortable truth: orchestration is where leadership lives

If you are a CTO, CPO, or head of product engineering, here is the quiet part out loud: orchestration forces accountability.

Prompting lets teams hide behind cleverness. Orchestration exposes whether you actually understand how value is created in your business.

Because the minute you try to orchestrate, you run into the real constraints:

  • Your data is scattered, permissions are inconsistent, and definitions disagree.
  • Your process is tribal knowledge, not a system.
  • Your edge cases are the product.
  • Your compliance needs are not optional, and your audit trail is not “we asked the model nicely.” (Microsoft Learn)

That is also why orchestration is a strategic advantage. It is hard precisely because it sits at the intersection of product, engineering, operations, security, and change management.

Why “AI users” will hit a wall

AI users become faster individuals. That is useful, but it is not compounding.

They save time on tasks that were never the bottleneck. They produce more artifacts, not more outcomes. They accelerate local productivity while the organization still moves at the speed of coordination.

Orchestration compounds because it scales across people. It turns expertise into a reusable workflow. It captures institutional knowledge in a living system, not in the heads of your best operators.

If you want a practical mental model, stop asking: “How do we get everyone to use AI?”

Start asking: “Which workflows, if orchestrated, would change our unit economics?”

A real-world smell test for orchestration readiness

If any of these sound familiar, you do not have an AI problem. You have an orchestration problem.

  • “We have great pilots, but nothing sticks.”
  • “We got a productivity bump, but delivery still feels chaotic.”
  • “We cannot trust outputs enough to automate anything material.”
  • “We are worried about security and compliance, so we are stuck in chat mode.”
  • “Everyone uses different prompts and gets different answers.”

Those are not model problems. Those are design problems.

The playbook: how teams move from AI use to AI orchestration

You do not need a moonshot. You need a workflow that matters, a thin orchestration layer, and ruthless clarity about quality.

  1. Pick one workflow with real stakes. Something with a clear definition of done. Not “research,” not “brainstorming.” Pick a job like triaging incidents, drafting customer responses with policy constraints, or converting messy inputs into structured records.
  2. Separate roles. Planning, execution, validation, and reporting should not be the same agent or the same step. That separation is the difference between a demo and a system. (OpenAI Developers)
  3. Build handoffs and guardrails, not a super-agent. Multi-agent orchestration exists because specialization plus controlled delegation is easier to debug and govern. (Microsoft)
  4. Make observability mandatory. Logging, tracing, and transcripts are not enterprise overhead. They are how you make AI behavior operational. (Microsoft Learn)
  5. Treat evaluation like CI. Define tests for correctness, policy compliance, and failure modes. If you cannot measure quality, you cannot scale automation. (Anthropic)

The new career moat

In the next two years, “good at prompting” will be like “good at Google.”

Nice. Expected. Not differentiating.

The career moat, and the organizational moat, belongs to the people who can do all of this at once:

  • translate business intent into workflows
  • connect tools and data safely
  • design guardrails and evaluation
  • ship systems that survive contact with reality

That is the orchestrator.

So yes, the gap will widen. But it will not be AI vs humans.

It will be AI users who generate more content versus AI orchestrators who design machines that reliably produce outcomes.

The Iron Triangle Is Back. AI Just Made It Sharper.

Every decade, the tech industry rediscovers a timeless truth and tries to dress it up as something new. Today’s version comes wrapped in synthetic intelligence and VC-grade optimism. But let’s be honest: AI did not kill the Iron Triangle. It fortified it.

For years we have preached that product decisions always balance quality, speed, and cost. You can choose two. The third becomes the sacrifice. AI arrives and many leaders immediately fantasize that this constraint has dissolved. It has not. It has only changed the failure modes.

AI accelerates coding. AI accelerates design. AI accelerates analysis. But the triangle still stands. What changes is which side collapses first and how painfully.

AI Makes “Fast” Frictionless and That Is the Problem

Teams adopt AI believing speed is now the default output. And in a sense it is. Prompt, generate, review, refine, and in minutes you have something that would have taken hours.

But the moment speed becomes effortless, the other two sides of the triangle take the hit.

Where things break:

  • Quality erodes quietly. Models hallucinate domain logic that engineers fail to notice. It compiles, it runs, and it is dangerously wrong.
  • Architectural discipline collapses. AI can ship features faster than teams can design scalable foundations. The result is a time bomb with fancy UX.
  • Costs compound through rework. The speed you gained upfront becomes technical debt someone must pay later, usually at triple the price.

AI made it easy to go fast. It did not make it safe.

AI Can Make Things “Cheap” but Often Only on Paper

Executives love AI because it hints at lower staffing costs, faster cycles, and higher margins.
They imagine a world where a handful of developers and designers can do the work of an entire department.

But here is the uncomfortable truth:

AI reduces the cost of creation, not the cost of correction.

The cheapest phase of a project is the moment you generate something. The most expensive phase is everything that comes after:

  • validating
  • integrating
  • securing
  • governing
  • maintaining
  • debugging
  • explaining to auditors why your model embedded training data into a client deliverable

AI does not make product development cheap. It simply delays the bill.

AI Promises “Quality” but Delivers Illusions of It

Platforms brag about AI-enhanced quality: fewer bugs, cleaner architecture, automated testing, smarter design. In reality, quality becomes performance theater unless teams evolve how they think, work, and review.

Common pitfalls:

  • AI code looks clean, reads well, and still violates half your constraints.
  • AI documentation is confident and completely fabricated.
  • AI test cases are shallow unless you explicitly direct them otherwise.

AI produces confidence without correctness. And too many leaders mistake the former for the latter. If you optimize for quality using AI, you must slow down and invest in human review, architecture, governance, and domain expertise. Which means speed suffers. Or costs rise.

The triangle always demands a price.

The Harsh Truth: AI Did Not Break the Triangle. It Exposed How Many Teams Were Already Cheating.

Before AI, many organizations pretended they could have all three. They could not, but the inefficiencies were human and therefore marginally manageable.

AI amplifies your ambition and your dysfunction.

  • Fast teams become reckless.
  • Cheap teams become brittle.
  • Quality-obsessed teams become paralyzed.

AI accelerates whatever you already are. If your product culture is weak, AI makes it weaker. If your engineering fundamentals are fragile, AI shatters them.

So What Do Great Teams Do? They Choose Deliberately.

The best product and engineering organizations do not pretend the triangle is gone. They respect it more than ever.

They make explicit choices:

  • If speed is the mandate, they pair AI with strict guardrails, strong observability, and pre-defined rollback paths.
  • If cost is the mandate, they track total lifecycle cost, not just dev hours.
  • If quality is the mandate, they slow down, invest in architecture, require human-in-the-loop validation, and accept that throughput will dip.

Great teams do not chase all three. They optimize two and design compensations for the third.

The Takeaway: AI Is Not a Shortcut. It Is a Magnifier.

AI does not free you from the Iron Triangle. It traps you more tightly inside it unless you understand where the real constraints have shifted.

The leaders who win in this era are the ones who stop treating AI as magic and start treating it as acceleration:

  • Acceleration of value
  • Acceleration of risk
  • Acceleration of consequences

AI is a force multiplier. If you are disciplined, it makes you unstoppable. If you are sloppy, it exposes you instantly.

AI did not remove the tradeoffs.
It made them impossible to ignore.

When Product Management Turns Into a Feature Factory

There is a point in every product organization where you can feel the shift. The roadmap gets longer. The backlog turns into a dumping ground for requests. The strategic narrative fades as the team becomes obsessed with throughput instead of outcomes. Somewhere along the way, product management stops being a strategic function and becomes a feature factory.

A feature factory is not just a bad habit. It is a structural failure. It is what happens when product managers are rewarded for saying yes, praised for velocity instead of value, and pulled into a cycle where their identity is tied to shipping rather than solving. The result is predictable. Teams build more. Customers benefit less. Companies lose ground and cannot explain why.

This post outlines how to identify when this shift is happening, what to do to avoid it, and the rare moments when accepting some feature factory behavior is the right move.

How to Identify a Feature Factory

1. Roadmaps read like grocery lists

A healthy roadmap is a narrative. It sets direction, creates context, and tells the story of where the product is going. When product management degrades into a feature factory, roadmaps lose this arc. They become tactical lists without a strategic spine.

2. Success is measured by output instead of outcomes

If conversations center on volume of shipped features rather than customer adoption, retention, or improved workflows, the factory is already running. Output becomes the proxy for impact and nobody notices when outcomes stall.

3. Product managers stop saying “no”

A strong product leader protects the product from noise. A weak one treats every request as valid and every stakeholder as a customer. When product management turns into a service desk, feature factory dynamics take hold.

4. Discovery becomes optional

A factory does not ask questions. It executes. When discovery is skipped, compressed, or treated as a luxury, the team is no longer building a product. They are manufacturing items that nobody validated.

5. The backlog is full of requests, not problems

The moment a backlog is dominated by “build X” instead of “solve Y,” you are dealing with a production line.

What to Do to Avoid the Feature Factory Trap

1. Establish a strategic narrative

Most feature factory behavior stems from the absence of a clear strategic point of view. Create a narrative that explains the future of the product and anchors decisions. Without strategy, execution becomes random.

2. Make problem statements mandatory

Require every feature request to contain a clear definition of the problem and the measurable impact. Without this rule, teams will overload themselves with solutions that lack purpose.

3. Treat discovery as a non negotiable discipline

Real discovery forces teams to question assumptions, evaluate alternatives, and validate outcomes. Build repeatable rituals for discovery and protect them with the same rigor used for delivery.

4. Communicate tradeoffs publicly

Feature factories thrive in silence. If leaders make tradeoffs visible and show what they are choosing not to do, teams will stop chasing volume for its own sake.

5. Drive incentives around client impact

If your performance culture celebrates shipping velocity, you will get shipping velocity. If you celebrate outcome velocity, you will get strategic progress.

When It Is Acceptable to Act Like a Feature Factory

There are rare moments when a factory mindset is both practical and necessary.

1. Stabilization periods

When the product has major reliability problems, the priority shifts to fixing issues as fast as possible. This is not strategy. This is survival.

2. Mandatory compliance requirements

Some obligations must be met. There is no strategic brilliance in responding to a new regulatory rule. Sometimes the right answer is to implement quickly and move on.

3. Short term commercial commitments

There are moments when a large enterprise client needs something specific to move forward. When the commercial value is clear and time bound, the team may need to operate with a delivery first approach. This should be done openly and with an understanding that it is temporary.

4. Technical debt reduction cycles

Technical debt requires systematic removal. These cycles often resemble factory work because the focus is narrow and execution heavy. The strategic value emerges later through improved velocity and quality.

In the end

A product organization that allows itself to drift into a feature factory is not simply making a tactical mistake. It is abandoning the core purpose of product management. Once the team becomes defined by volume instead of value, strategic clarity evaporates, talent erodes, and the product becomes indistinguishable from any commodity tool in the market.

The real danger is not that teams ship too much. The real danger is that they stop thinking. They stop challenging assumptions. They stop shaping the future of the business. They become efficient at the wrong things.

Leaders who tolerate this drift are choosing short term comfort over long term competitiveness. They are trading strategic advantage for a temporary sense of productivity. It is a quiet form of organizational self harm.

Great product companies refuse to operate this way. They treat strategy as a discipline, discovery as a requirement, and outcomes as the only scoreboard that matters. Anything less is not product management. It is administrative labor wrapped in a product title.

If your team feels like a factory, the problem is not capacity. The problem is leadership.