Tag: eval-driven development

  • How to Operate AI Customer Agents as a Reliable CX System

    How to Operate AI Customer Agents as a Reliable CX System

    AI customer agents are expanding from answering routine questions toward handling complex workflows and potentially supporting more of the customer lifecycle. The operational challenge is no longer simply whether an agent can produce a plausible answer. It is whether the organization can keep that agent accurate, controlled, measurable, and ready whenever the business changes.

    Taken together, the source reports point to a practical operating model: connect product releases to knowledge updates, test behavior before exposure, measure the full interaction rather than a narrow survey sample, and assign people to improve the system continuously. That turns an AI agent from a channel feature into managed CX infrastructure.

    Key takeaways

    • Agent reliability depends on a continuous train, test, deploy, and analyze cycle, not a one-time implementation.
    • A product release is not operationally complete until the agent has current, unambiguous, and retrievable information about it.
    • Pre-release evaluation should test realistic customer questions, policy conditions, system actions, and required human handoffs.
    • Survey metrics remain useful, but conversation-level analysis provides broader visibility into answer quality, effort, sentiment, and recurring friction.
    • Human roles increasingly shift toward knowledge stewardship, exception handling, policy design, evaluation, and cross-functional CX improvement.

    Treat the agent as a product system, not a chatbot

    The Pioneer 2025 report describes Fin 3 through four operating stages: training, testing, deployment, and analysis. It reports that Procedures combines natural-language instructions with deterministic controls for complex work, while Simulations is intended to test behavior before customers encounter it. The report also describes deployment across additional channels, including Slack and Discord, improvements to Voice, and analytics features such as CX Score Reasons and Topic Trends.

    These are vendor-reported capabilities, but the underlying operating principle applies beyond one platform. An agent that can act in business systems needs more than fluent language generation. It needs explicit procedures, boundaries on what it may do, test cases that expose failure modes, controlled channel deployment, and evidence showing what happened after release.

    The same report presents a longer-term Customer Agent vision built around roles, goals, persistent memory, business knowledge, and interoperability. That vision should be distinguished from currently reported product functionality. It nevertheless clarifies the governance challenge: as an agent gains continuity and operational reach, errors can travel across more stages of the customer journey. Ownership of objectives, data, permissions, escalation, and measurement therefore becomes part of CX design.

    This also changes how success should be framed. Resolution volume is an operational output, but a dependable CX system must also answer whether the agent followed policy, used current knowledge, completed the intended action, recognized an exception, and left the customer with an acceptable amount of effort. Automation without those checks can move work while concealing deterioration in the experience.

    Move agent readiness into the product release process

    The NPI playbook focuses on a common source of agent failure: products change faster than their supporting knowledge. When a feature launches without usable documentation, the source reports that the agent may hand conversations to people just as launch-related volume rises. The resulting backlog is therefore not only a support problem; it is a release-readiness problem.

    A stronger definition of done includes agent readiness. The NPI source recommends bringing support or knowledge specialists into product walkthroughs, product marketing kick-offs, and pre-release testing. It also calls for a named owner, whether an NPI manager, knowledge manager, support lead, or product operations owner. The title can vary, but accountability cannot be distributed so widely that nobody verifies readiness.

    The required knowledge must be designed for retrieval as well as human reading. According to the source, documentation should include both internal feature names and the phrases customers actually use, expand acronyms, state plan and availability conditions explicitly, and reproduce the substance of screenshots or videos in text. This is important because information can be technically present yet remain difficult for an agent to retrieve or apply correctly.

    Release work must also remove knowledge that a launch has invalidated. Searching related articles, macros, notes, and workflows can reveal stale or contradictory guidance. Duplicate content deserves particular attention: competing versions of an answer can create inconsistent agent behavior even when the newest article is accurate.

    Testing then connects knowledge preparation to customer outcomes. The NPI playbook recommends assembling likely questions from launch content, beta feedback, and early support conversations; running them in the environment customers will use; rating the answers; correcting the underlying content or structure; and repeating the evaluation. Conditions such as phased rollout, plan eligibility, regional availability, and mandatory human escalation require explicit coverage rather than an assumption that the agent will infer the right behavior.

    This creates a two-speed control model. Before launch, teams test expected questions and known edge cases. After launch, they watch real conversations for unexpected language, missing scenarios, or product behavior that the original documentation did not anticipate. The feedback should return to the release tracker, knowledge source, procedure, or product team according to the root cause.

    Measure experience at conversation scale

    Release evaluation shows whether an agent appears ready, but production measurement shows whether that readiness survives real customer behavior. The CX measurement source reports that CSAT captures less than 10% of conversations and that respondents tend to represent more extreme reactions. On that account, survey results leave a large unobserved middle and cannot by themselves explain whether dissatisfaction arose from service, product behavior, or policy.

    The source describes an alternative in which AI evaluates every human and agent interaction across dimensions such as service quality, resolution, and customer effort. It reports that Intercom’s CX Score assigns interactions a score from 1 to 5, exposes reasons behind the score, and gives most teams roughly five times the coverage of CSAT alone. Those product-specific claims are reported by the source rather than independently verified here, but they illustrate the broader distinction between voluntary feedback and systematic conversation review.

    Fuller coverage does not make direct customer feedback obsolete. CSAT can still capture what a customer chooses to say, while conversation analysis can detect repeated explanations, handoff friction, weak answer quality, unresolved intent, and neutral interactions that generate no survey response. The two signals answer different questions and should be interpreted together rather than forced into a single interchangeable benchmark.

    New coverage also requires new baselines. The measurement source cautions against transferring an old CSAT target directly to a conversation-scoring system because the populations and methods differ. It recommends correlating the new score with operational measures such as first response time and time to close, then examining underlying attributes including answer quality, customer effort, and product feedback. Its illustrative targets of 80% for Fin support, 70% for human support, and 78% overall are examples derived from the scenario described in that article, not universal standards.

    Segmentation is equally important. Complex, high-touch cases should not automatically be compared with transactional contacts, and aggregate results can hide a poorly performing topic or channel. Useful analysis separates agent and human conversations, examines topics and handoffs, and preserves context about case type. The most actionable output is not the score alone but a reason that can be routed to a responsible owner.

    Build one improvement loop across CX, product, and knowledge

    The sources approach AI customer agents from different angles: the Pioneer report emphasizes expanding capabilities and a broader customer-agent vision; the NPI playbook concentrates on release and knowledge readiness; and the measurement article addresses visibility after deployment. Their combined implication is that these activities cannot remain separate programs.

    A low-quality interaction might originate in several places. The knowledge may be missing or contradictory, the procedure may express the wrong policy, the product may behave unexpectedly, the agent may fail to retrieve applicable information, or the case may require a human specialist. Conversation-level reasons help locate the problem, but the organization still needs a route from evidence to correction and then to re-evaluation.

    That operating loop changes human work. Customer-facing specialists remain essential for sensitive, ambiguous, or exceptional cases, while also contributing customer language, testing scenarios, escalation criteria, and knowledge improvements. Product and engineering teams become accountable for the support consequences of releases. Knowledge teams manage information as production input, and CX leaders set objectives that balance resolution, effort, policy compliance, and service quality.

    The most revealing opportunities may sit in interactions that are neither failures nor successes. Broader conversation analysis can surface answers that were technically acceptable but unnecessarily difficult, impersonal, or incomplete. Improving that middle ground requires more than tuning a model: it may require clearer documentation, a better workflow, a product fix, or a different escalation rule.

    As agents acquire more roles, memory, knowledge, and access to business systems, CX operations will increasingly resemble product operations for a continuously changing service. Organizations that establish release gates, evaluation sets, conversation-level diagnostics, and unambiguous ownership will be better positioned to expand agent responsibility without allowing reliability to become an afterthought.

    References

  • AI Product Leadership: Faster Learning, Safer Systems

    AI Product Leadership: Faster Learning, Safer Systems

    AI-enabled product leadership is not primarily a contest to automate more work. The stronger opportunity is to shorten learning loops while improving the quality, traceability, and safety of product decisions.

    Across the five source articles, a common operating model emerges: begin with bounded problems, connect AI to real customer evidence, define quality through domain expertise, and make safeguards proportional to the consequences of failure. This model applies both to internal product workflows and to customer-facing AI systems.

    Move from an AI tool stack to an evidence system

    The article on essential tools for product managers presents AI as a working layer across product intelligence, research, analytics, roadmapping, design, prioritization, and delivery. Its most useful implication is that tool selection should begin with the decision a team needs to improve, not with the number of AI features available.

    A feedback summarizer, behavioral analytics platform, prototyping assistant, and requirements generator can each save time. Their strategic value appears when their outputs are connected: qualitative feedback helps explain observed behavior, behavioral evidence tests assumptions raised in interviews, and both inform prioritization. The product manager still has to reconcile customer pain, business outcomes, engineering effort, differentiation, and stakeholder expectations.

    The practical guide to finding AI use cases reaches the same conclusion from a different direction. It recommends starting with a concrete item from everyday work, testing how AI might help, and studying the gap between the desired result and the output. It specifically proposes a 15-minute daily practice and treats an initially poor result as evidence about instructions, context, constraints, or model capability.

    Together, these perspectives suggest two complementary levels of adoption. At the individual level, task-first experimentation builds judgment about what AI can do. At the team level, connected evidence workflows turn that judgment into a repeatable product operating system. Buying tools without the first creates shallow adoption; isolated personal experiments without the second produce scattered efficiency rather than organizational learning.

    Use AI to deepen discovery, not to create distance from customers

    The 2026 roadmap article frames roadmaps as portfolios of experiments involving products, learning methods, teaching models, and choices about what to stop doing. It argues that AI can reduce tedious discovery work and provide feedback on demanding skills, including interviewing, assumption testing, and opportunity mapping. At the same time, it warns against substituting agents or dashboards for human curiosity and direct customer contact.

    That tension supplies an important boundary for AI-enabled discovery. Models can organize notes, identify recurring themes, critique an interview guide, expose possible confirmation bias, or compare evidence across sources. They cannot independently determine whether the team asked the right customers, understood the social context, or interpreted ambiguous language correctly. Those remain product and research judgments.

    The safety-first consent coach described in the Override Labs article illustrates why context matters. According to that account, the nonprofit examined 2,000 Reddit posts per subreddit to validate demand and understand how vulnerable questions were expressed. The discovery material included uncertainty, shame, peer pressure, and the possibility that someone might be seeking permission rather than reflection. A conventional feature request or decontextualized summary could have obscured those conditions.

    The cross-team review reinforces this point through other domains. It reports that former teachers at eSpark created evaluation rubrics based on how educators assess student work and enriched educational content with domain-specific metadata when generic embeddings produced weak matches. It also describes how local-government knowledge at Zencity changed the interpretation of sentiment, and how incident-response experience informed Incident.io’s investigation architecture. Across these examples, AI increased the importance of domain expertise because people still had to define what relevance, quality, and failure meant.

    Let the consequence of failure determine the product architecture

    Not every AI-assisted task needs the same controls. A weak draft of an internal stakeholder update can be reviewed and corrected cheaply. A response that could be interpreted as permission in a consent-related situation has a fundamentally different risk profile. Responsible product development begins by distinguishing those cases before selecting architecture or interaction patterns.

    The Override Labs account offers the clearest high-stakes pattern. The team reportedly defined a "South star" around the worst outcome: a teenager using the product response as a green light for harmful action. The product therefore avoids giving a green-flag verdict. It runs deterministic risk classification before calling Claude, adjusts responses by risk tier, and uses a structure that validates, reflects, and invites further reflection. A licensed therapist contributed to the evaluation rubric, while positive masculinity coaches helped shape the tone.

    The underlying principle is broader than that implementation. A generative model should operate inside a product-defined safety system rather than becoming the safety system. Product leaders can translate that principle into four design questions: what outcome must never be encouraged, which decisions require deterministic handling, when should generation be constrained or withheld, and which domain experts are qualified to judge the response?

    The review of AI product teams adds another trust boundary: deciding when a system should admit that it does not know. This is both a model-quality issue and a product behavior. Teams need to specify what insufficient evidence looks like, what the interface communicates in that state, and whether the user should retry, provide more context, consult a person, or stop the workflow.

    This risk-based approach avoids two unhelpful extremes. Applying high-stakes controls to every low-consequence drafting task can make experimentation needlessly heavy. Treating sensitive decisions like ordinary content generation can leave critical failure modes to probabilistic behavior. The appropriate control set follows the plausible harm, reversibility, affected population, and user’s ability to detect an error.

    Make evaluation, privacy, and leadership part of delivery

    The production-team review describes evaluation as an evolving operational capability rather than a final test. It reports that Stack Overflow ran about 50 experiments across five pods in three months, produced four versions of an AI-powered search product, and ultimately stopped that effort. Arize began building its Alyx agent before established agent frameworks were available, while eSpark’s former teachers learned to write evaluation code with LLM assistance. These are source-reported examples, not independently verified benchmarks, but they demonstrate how structured learning can support both shipping and stopping decisions.

    Evaluation should therefore start when the use case is defined. Early rubrics can be simple: representative tasks, expected properties, unacceptable outputs, and a review process. As the product matures, teams can add risk tiers, regression sets, production observations, and explicit release criteria. The goal is not to claim that a model is universally good; it is to establish whether a particular system performs acceptably within a bounded workflow.

    Privacy belongs in the same product definition. The consent-coach article reports that the service uses no accounts, cookies, or cross-session tracking. That choice limits conventional retention analytics, but it also supports the trust required for a sensitive interaction. It shows that less data can be a deliberate product feature when identification or surveillance would discourage honest use.

    Leadership determines whether these practices persist. The roadmap article argues that training alone does not change an organization when leaders continue to reward old behaviors. Its proposed learning model combines on-demand material, AI-generated feedback, coaching resources, and human support. The practical-use-case article similarly recommends peer demonstrations and structured practice. Both suggest that AI readiness is a management system: teams need permission to experiment, shared examples, quality standards, and leaders who reinforce evidence-based behavior.

    Key takeaways

    • Start with a bounded task and a defined outcome; use repeated practice to learn where AI adds leverage and where it fails.
    • Connect research, feedback, behavioral data, prioritization, and delivery so that AI improves decisions rather than producing isolated artifacts.
    • Keep direct customer contact and domain expertise at the center of discovery, synthesis, and quality judgment.
    • Define the worst credible outcome before designing a customer-facing AI experience, then match controls to that risk.
    • Build evaluation and privacy into the product operating model, including criteria for refusing, escalating, or admitting uncertainty.
    • Measure AI leadership by better learning and safer outcomes, not by tool count, output volume, or automation alone.

    Building the next product operating rhythm

    The next step for product organizations is not a universal AI playbook. It is a disciplined rhythm in which teams choose a real problem, gather contextual evidence, define acceptable and unacceptable behavior, test a bounded intervention, and revise or stop it based on results. As AI capabilities change, that rhythm can remain stable. It gives product leaders a way to pursue faster learning without treating speed as a substitute for responsibility.

    References

  • Reliable AI Coding Requires Four Kinds of Control

    Reliable AI Coding Requires Four Kinds of Control

    Reliable AI coding is not primarily a matter of finding a better prompt or a more capable model. It is a workflow-design problem: teams must control what the product should do, what the repository currently does, what the model can see, and what the agent is allowed to change.

    Managing those four kinds of state turns an AI coding session from an open-ended conversation into a bounded engineering process. The payoff is faster iteration without treating plausible output, confident status messages, or large context windows as substitutes for evidence.

    Reliability depends on the surrounding system

    A large language model generates an answer token by token from the input available to it. That input can include more than the visible request: an application may add system instructions, conversation history, project files, enabled tools, skills, and other supporting context. As Shivam.Consulting Blog’s guide to how ChatGPT works explains, the surrounding application therefore helps shape the result even when two products use the same underlying model.

    This mechanism has an important operational consequence. An agent can produce code that looks convincing without possessing a stable model of the intended product, the complete repository, or the runtime environment. Fluency indicates that the output fits learned patterns; it does not establish that the implementation satisfies the requirement.

    A dependable workflow consequently controls four connected states. Product state covers requirements, constraints, permissions, edge cases, and acceptance criteria. Repository state covers the actual code, data model, dependencies, tests, and uncommitted changes. Model state covers the instructions and evidence present in the context window. Execution state covers tools, filesystem access, commands, network activity, and other permissions. A failure in any one can appear to be a coding error even when the code is not the original cause.

    Tool selection should reflect that distinction. Shivam.Consulting Blog’s vibe-coding playbook recommends managed app builders when the purpose is to explore an interaction or answer an early product question, while positioning developer-oriented coding agents as more appropriate for existing repositories, multi-file changes, tests, and review workflows. The useful dividing line is not whether a tool can generate code. It is whether the environment exposes enough control and evidence for the consequence of the change.

    Convert product intent into a bounded change contract

    Many unreliable sessions begin before an agent edits a file. If the requested behavior, non-goals, affected users, data rules, and observable success conditions remain ambiguous, the model must fill the gaps. Each follow-up correction can then preserve a different assumption, creating a chain of locally plausible patches without a coherent final design.

    A stronger starting point is a compact change contract written outside the chat. It should identify the outcome, relevant current behavior, permitted scope, important invariants, expected edge cases, and the evidence that will demonstrate completion. For a defect, that evidence begins with a reproducible failing case. For a feature, it includes examples of accepted and rejected behavior. The contract should also record explicit non-goals so that an agent does not broaden a narrow request while attempting to be helpful.

    Blast radius deserves separate attention. The vibe-coding playbook uses data, controller, and view as a practical three-layer model. A request involving permissions, sorting, filtering, workflow state, or reporting may cross all three even if it appears in the interface as a small change. Reviewing the planned impact across storage, logic, and presentation helps reveal missing migrations, inconsistent validation, stale queries, and user-interface states before implementation begins.

    The same source proposes separate plan-review-fix and implement-review-fix loops. Combined with the change contract, these become distinct gates rather than one continuous conversation. The plan gate asks whether the proposed files, layers, and tests match the requirement. The implementation gate asks whether the resulting diff and observed behavior match the approved plan. Separating the gates makes it easier to reject a mistaken approach before it accumulates code.

    This structure also clarifies the human role. The agent can explore the repository, propose a plan, implement a bounded change, and help investigate failures. Product and engineering owners remain responsible for deciding what behavior is correct, which tradeoffs are acceptable, and what evidence is sufficient to ship.

    Treat context as a limited working set, not permanent memory

    A long conversation can feel comprehensive while becoming less dependable. Shivam.Consulting Blog’s context-rot analysis reports research showing that model performance can deteriorate as input length grows and that information at different positions may receive unequal attention. The article’s practical conclusion is more useful than any advertised context-window maximum: available capacity should not be confused with reliable attention.

    Context should therefore be curated as a task-specific working set. Durable facts belong in versioned project documents; the active session should receive only the instructions, files, decisions, and evidence needed for the current change. Old tool output, abandoned plans, duplicate explanations, and superseded requirements consume attention without improving the task.

    Shivam.Consulting Blog’s guide to Claude Code workflows describes a layered memory pattern: broad preferences in global instructions, project-specific conventions in repository-level files, and reference material loaded when relevant. It also presents stored commands as a way to make recurring procedures explicit, and sub-agents as a way to isolate context or perform independent work. The transferable principle is architectural rather than product-specific: stable policy, project knowledge, task instructions, and transient evidence should not be mixed into one ever-growing transcript.

    A clean session boundary can be a reliability control. When a conversation has accumulated contradictory instructions or repeated failed fixes, the next step should not automatically be another patch request. A new session can begin from a short handoff containing the approved change contract, current repository state, attempted approaches, observed failures, and unresolved questions. This preserves useful evidence without carrying the entire history forward.

    Sub-agents require the same discipline. Parallelism is valuable when work can be partitioned into independent questions, such as locating relevant code, examining tests, or reviewing a proposed diff. It is less useful when several agents can modify overlapping files or make incompatible architectural assumptions. Each delegated task needs a narrow scope, an expected output, and a rule for whether it may write or only report.

    Require evidence, limited authority, and a recovery path

    An agent’s statement that a problem is fixed is a claim to verify, not completion evidence. Verification should return to the original reproducer or acceptance criteria, then examine the diff and run the smallest relevant checks. Broader tests can follow when the change crosses modules, alters shared behavior, or affects data. This sequence distinguishes a real correction from a patch that merely changes the visible symptom.

    Review should inspect both behavior and change shape. A diff may pass a narrow test while introducing unrelated refactoring, weakening validation, swallowing errors, or duplicating logic. Unexpected file changes, new dependencies, disabled checks, and unusually broad edits are signals to pause. If the evidence is inconclusive, the workflow should return to diagnosis rather than asking the same context-saturated agent to keep editing.

    Reliability also depends on limiting what an agent can do. Shivam.Consulting Blog’s Claude Code risk guide describes escalating exposure as an agent moves from reading a project folder to reading elsewhere, fetching external material, writing files, executing generated code, and installing third-party packages or extensions. Although permission models vary by product, the general control is consistent: grant the least authority required for the current step and review the exact path or command before approval.

    Folder boundaries should match the task boundary. Credentials, customer information, confidential documents, and unrelated projects should not be placed within an agent’s working scope. One-time approval is preferable when an operation is unusual or its future use would be difficult to predict. Commands that delete, overwrite, upload, install, or execute deserve more scrutiny than read-only inspection because their impact is larger or harder to reverse.

    Reversibility completes the control system. The safety guide emphasizes backups and version control because an AI coding interface may not provide a dependable undo operation. A clean checkpoint before implementation, small commits, reviewable diffs, protected secrets, and a tested rollback path reduce the cost of both model errors and human approval mistakes. For higher-risk work, the agent should operate in a disposable branch, isolated environment, or similarly constrained workspace rather than directly against valuable state.

    These safeguards are mutually reinforcing. A bounded contract limits scope; curated context reduces instruction drift; verification exposes incorrect claims; least privilege limits blast radius; and version control makes recovery practical. Removing any one of them shifts too much trust onto probabilistic output.

    Key takeaways

    • Control product state, repository state, model context, and execution authority as separate parts of one workflow.
    • Write a change contract with scope, non-goals, invariants, edge cases, and acceptance evidence before implementation.
    • Keep context task-specific; store durable knowledge in files and start a clean session when history becomes contradictory or noisy.
    • Treat an agent’s completion report as a hypothesis until the original reproducer, relevant tests, observed behavior, and diff support it.
    • Match permissions and isolation to the risk of the operation, and create a recovery point before allowing changes.

    As coding agents gain more tools and autonomy, reliable teams will distinguish themselves less by how much work they delegate than by how clearly they define authority, evidence, and recovery. The durable advantage will come from workflows in which faster generation is paired with tighter control.

    References

  • AI Inference Economics: Optimize for Value, Not Cost

    AI Inference Economics: Optimize for Value, Not Cost

    AI inference economics cannot be reduced to the price of a model call. The financially relevant question is whether a change in model, latency, caching, or token use improves total product value after its effects on conversion, retention, support, and revenue are included.

    A reported decision to reject a projected $2 million in inference savings illustrates the distinction. The supplied source describes lower infrastructure costs alongside weaker downstream product signals, making the proposed optimization look attractive in a FinOps report but less compelling at the business level.

    The correct unit of analysis is the customer outcome

    Cost per request is useful for operating an AI product, but it is not a complete measure of its economics. A cheaper request can still be expensive if it makes a user more likely to abandon a session, fail a task, contact support, or leave the product.

    The source article reports that routing traffic to lower-cost options produced immediate cloud cost optimization. It also associates small increases in time to first token with greater session abandonment, subtle quality declines with lower task completion, and weaker performance in support deflection. According to the account, the resulting revenue exposure exceeded the projected expense reduction.

    This reframes inference efficiency as a value equation. Direct serving cost belongs on one side; incremental conversion, retained revenue, successful task completion, and avoided support demand belong on the other. The decision should be based on the net effect rather than whichever metric is easiest to retrieve from a cloud bill.

    Cost, latency, and quality form a coupled system

    Model cost, response speed, and output quality are often managed as separate workstreams. In practice, changing one can move the others. A smaller or cheaper model may reduce inference expense while changing answer quality. More restrictive token limits may shorten responses but remove information needed to complete a task. Caching may improve both cost and speed for repeatable requests, yet become unsuitable where fresh or highly contextual output matters.

    The source argues for treating these variables as one product system. That view prevents a local optimization from being mistaken for an overall improvement. It also makes latency distributions more informative than a single average: even when aggregate performance appears acceptable, slower experiences within particular workflows may coincide with abandonment or failed completion.

    The same principle applies to quality. A model-level score matters only insofar as it represents what users need from the workflow. For a support agent, that might involve resolving an issue without escalation. For another product experience, it might involve completing a task, activating a feature, or continuing to use the service. Business instrumentation gives technical measures an economic interpretation.

    Experiments must detect product harm, not just cost movement

    The reported evaluation combined eval-driven development with A/B testing and defined success through conversion, retention cohorts, and Net Recurring Revenue rather than cost per call alone. It also used minimum detectable effect calculations to determine whether the tests had enough statistical power to reveal meaningful changes in latency and answer quality.

    That approach suggests two complementary layers of evidence. Evaluations can identify whether model behavior changes on representative tasks, while controlled product experiments can show whether those changes matter to users and the business. Neither layer is sufficient by itself: an offline quality score may miss behavioral consequences, and a topline business metric may conceal the mechanism behind a regression.

    Guardrails are especially important when the expected saving is immediate but the product damage may emerge later. Infrastructure spend can fall as soon as traffic moves. Retention and recurring-revenue effects may take longer to appear. Conversion, task completion, session abandonment, support deflection, and cohort retention therefore provide signals across different time horizons.

    The evidence supplied here is one first-person case account, not independent corroboration. Its projected $2 million saving, observed correlations, and business conclusion should consequently be treated as case-specific rather than universal benchmarks. The transferable value lies in the measurement framework, not in assuming that every higher-cost model will produce a better commercial outcome.

    Key takeaways

    • Evaluate inference changes against total product value, including conversion, retention, support demand, and recurring revenue.
    • Measure cost, latency, and AI quality together because an intervention in one dimension can alter the others.
    • Pair task-level evaluations with controlled product experiments and size tests to detect economically meaningful regressions.
    • Apply optimization selectively: a technique is valuable where evidence shows that it lowers cost without harming the customer outcome.

    A selective optimization roadmap

    The alternative to indiscriminate cost cutting is not unlimited inference spending. The source describes a balanced roadmap built around targeted caching where experiments showed no adverse outcome, dynamic routing for task-specific workloads, and stronger observability to detect quality regressions early.

    Each method addresses a different part of the economics. Targeted caching can remove redundant work in stable interactions. Dynamic routing can reserve more capable models for tasks that justify them while sending simpler work to less expensive paths. End-to-end observability can connect routing, model, token, latency, and quality data with the behavior that follows.

    This also clarifies governance. FinOps teams can continue applying pressure to unit costs, while product teams define outcome guardrails and analytics teams verify the net effect. A proposed saving becomes ready for broader rollout only when the organization can see both the expense reduction and the customer or revenue impact.

    As AI products scale, the strongest operating discipline will be selective rather than reflexive: spend less where evidence supports it, invest more where inference creates measurable value, and revisit routing decisions as workflows and user behavior change.

    References

  • How I Use Novus, the First Product Agent, to Turn Rapid Releases into Measurable Wins

    In a world of relentless CI/CD and accelerating release trains, product leaders like me can’t afford lagging signals or fuzzy readouts on what’s truly moving the needle. I need immediate, trustworthy feedback that connects code shipped to outcomes achieved and customer value created.

    Coding agents compress weeks of development into hours, but the faster your codebase changes, the harder it is to know what’s actually helping end-users.

    That tension is exactly why I brought Novus into my product toolbox. To keep up with the pace of development, over 600 product teams are already using Novus, the first-of-its-kind product agent, to automatically set itself up, monitor product data, and tell you what to do next.

    From my chair, that promise matters only if it translates into clear decisions. With Novus, I’ve been able to tighten the loop between experimentation and learning: it pairs eval-driven development with behavioral analytics and observability so I can see how a release influences activation, engagement, and retention—without spelunking through fragmented dashboards. The agentic AI backbone reduces the manual stitching I used to do across events, cohorts, and funnels, letting me focus on prioritization and product strategy instead of report wrangling.

    Day to day, Novus fits naturally into our AI workflows. It surfaces anomalies early, clarifies trade-offs, and frames next-best actions in the language of outcomes. Because it plugs into a unified analytics platform approach, I can maintain continuous discovery at scale while preserving the rigor of Agent Analytics: hypotheses are explicit, telemetry is consistent, and results are traceable. That’s the operating cadence I expect from modern product management leadership.

    If your roadmap moves faster than your learning loops, a product agent can be the missing link between speed and certainty. Novus helps me convert rapid releases into measurable wins, keeping the team aligned and confident about what to build next—and just as importantly, what to stop doing.

    Inspired by this post on Pendo – Best Practices.

    Book a consult png image

  • Claude Code for Product Managers: Accelerate Prototypes, Validate Faster, Ship with Confidence

    I build products under constant pressure to learn faster without breaking trust. Claude Code has become a pragmatic addition to my AI product toolbox because it helps me move from idea to evidence with less friction—while keeping engineering, design, and compliance in the loop.

    “Claude Code for Product Managers explained: what it is, why it matters, and how it helps PMs prototype, validate, and move faster.” That line captures the essence. In practice, I use it to turn ambiguous problem statements into tangible artifacts—API stubs, SQL queries, test data, and lightweight prototypes—that sharpen conversation and accelerate decision cycles.

    What is it in PM terms? A code-aware assistant that helps me prototype safely and quickly. I can generate example API calls, transform messy CSVs for retention analysis, draft instrumentation plans for Amplitude analytics, or spin up a mock service to validate an integration. Because it understands structure, it’s effective at scaffolding small utilities (e.g., a data cleaner or a CLI harness) that make discovery and validation faster.

    Day to day, Claude Code reduces handoffs. If I’m exploring a new partner integration, I’ll have it produce a curl library and a Postman collection, then annotate each step with acceptance criteria and expected responses. When I’m shaping a feature, I lean on it to outline event taxonomies and feature flags so that engineering can wire telemetry without guesswork. For insights work, I’ll ask it to propose SQL for cohort, funnel, and retention analysis—always verifying against source schemas before anything touches production.

    Speed is only useful when it improves signal quality. I anchor the workflow in continuous discovery: small hypotheses, thin-slice prototypes, and fast instrumentation. Claude Code helps me estimate A/B testing readiness (including minimum detectable effect), generate smoke tests for critical user paths, and structure an eval-driven development loop so we learn from every iteration. It also supports context window management by summarizing long PRDs into the few constraints a prototype must respect.

    Governance matters. I apply AI readiness and AI risk management principles: never paste secrets or PII, isolate sandboxes, and log prompts as docs-as-code for auditability. I prefer a retrieval-first pipeline that feeds approved product docs, OpenAPI specs, and design tokens so generations stay grounded. When tools are integrated, I favor the Model Context Protocol (MCP) to constrain capabilities and maintain least-privilege access. Human-in-the-loop review is non-negotiable—especially for anything that might influence customer data or pricing.

    The best outcomes show up in product trios. I’ll facilitate a live session with design and engineering: we co-create prompts, compare alternatives, and converge on a thin slice we can ship. That collaboration keeps us empowered, reduces interpretation drift, and turns Claude Code into an accelerant rather than a sidecar. Over time, the trio curates a reusable prompt library for PRD outlines, experiment checklists, and integration playbooks.

    Getting started is straightforward: define a safe environment, assemble your authoritative corpus (requirements, specs, taxonomies), and codify a few high-value templates—API exploration, instrumentation plans, sandbox data generators, and acceptance tests. Track impact with simple, objective metrics: cycle time from hypothesis to instrumented prototype, time-to-first-signal, and the proportion of decisions made with data versus opinion.

    There are pitfalls. Hallucinated fields can creep into API calls, schema drift can break generated queries, and “clever” refactors may miss edge cases. I mitigate this by grounding generations in current specs, asking for unit tests alongside any code, and validating against a staging environment before anyone talks about production. Treat Claude Code as a collaborator, not an oracle.

    If your mandate is to learn faster, de-risk bets, and ship with confidence, Claude Code is worth adopting. Used thoughtfully, it compresses the distance between questions and answers, elevates product discovery, and lets teams validate more ideas with fewer meetings—without compromising on governance or quality.

    Inspired by this post on Product School.

    Book a consult png image
  • Beyond Black‑Box Scores: Custom AI That Elevates Trust & Safety Without Burnout

    Beyond Black‑Box Scores: Custom AI That Elevates Trust & Safety Without Burnout

    What do you do when off-the-shelf moderation scores aren't good enough—and the alternative is paying human contractors to spend their days reviewing traumatizing content at scale? I’ve wrestled with that exact trade-off in enterprise environments, and it’s why I was eager to unpack how custom AI can raise the bar on trust and safety without compromising accuracy, latency, or the well-being of our teams.

    In this episode of Just Now Possible, I sit down with Nikki Marinsek (Data Scientist), Brian McCaffrey (Software Engineer), and Dan Means (Machine Learning Engineer) from Musubi, an AI-native trust and safety toolkit for content platforms. Musubi builds custom-trained ML models and LLM-powered moderation tools that adapt to each platform's unique policies—from dating apps to social networks to AI inference endpoints. As a product leader, I’m drawn to their blend of eval-driven development, agentic AI, and pragmatic deployment pipelines that actually meet real-world SLAs.

    We walk through their full journey—starting with a first prototype on tabular data—then discovering the system was sometimes catching issues human moderators missed. That insight became a forcing function to formalize evaluation, calibrate thresholds, and design feedback loops that help humans and models converge. Just as importantly, they built a policy optimizer that uses agentic flows so non-technical trust and safety teams can iterate on LLM moderation policies without needing a data scientist in the room.

    If you’ve ever had to balance latency, accuracy, and cost at scale, you’ll appreciate how Musubi tests trade-offs across traditional ML, embedding-driven classification, and LLMs. Their approach mirrors the patterns I expect in high-throughput stacks: cache and pre-compute where possible, contain worst-case latencies, and push evaluation tooling to customers so policy changes are safe, observable, and fast to deploy.

    What resonated most with me is their core product strategy: put eval tools directly in customers’ hands. When teams can benchmark AI against humans, referee disagreements using “LLM as judge,” and make policy gaps visible, trust increases and operational drift decreases. That’s the foundation for durable product strategy in sensitive domains like content moderation, fraud management, and risk scoring.

    Listen to this episode on: Spotify | Apple Podcasts

    Guests: Nikki Marinsek, Data Scientist, Musubi; Brian McCaffrey, Software Engineer, Musubi; Dan Means, Machine Learning Engineer, Musubi.

    In this episode: Why off-the-shelf moderation scores fail and how custom-trained models fix that; How Musubi combines traditional ML with LLMs for different moderation tasks; The discovery that AI can outperform human moderators—and how to communicate that to clients; Using AI as a judge to referee disagreements between AI and human decisions; How Musubi onboards new customers with "reverse demos"; What custom model training actually means: fine-tuning, feature engineering, and reusable deployment pipelines; The policy optimizer: an agentic flow that helps customers iterate on their LLM moderation policies; Why pushing eval tools directly to customers is a core product strategy; How Musubi is building flexible orchestration workflows for non-technical trust and safety teams.

    From a product management lens, a few highlights stand out. First, the disciplined separation of concerns: use traditional ML for high-precision, low-latency pattern detection and LLMs for nuanced policy interpretation. Second, invest in golden sets and policy loops early so you can quantify improvement and avoid subjective debates. Third, productize customization—create reusable deployment pipelines, parameterized policies, and self-serve evaluation—so each customer’s “custom model” still scales like a platform.

    I also appreciated the onboarding tactic of "reverse demos." Rather than a canned walkthrough, the team invites customers to bring real policies and edge cases, then instruments the workflow live. That move builds credibility, accelerates discovery, and surfaces the fastest paths to value—an approach I recommend whenever you’re selling complex AI workflows to non-technical stakeholders.

    If you’re navigating cost and latency trade-offs, the conversation goes deep on techniques like embedding-driven classification, fine-tuning vs. training, and when to route decisions through LLM adjudication. My takeaway: treat the router, the evaluator, and the policy as first-class products. When those elements are observable and testable, you can raise quality without exploding compute costs or creating operational bottlenecks.

    Resources & Links: Musubi — AI-powered trust and safety toolkit for content platforms. Maven AI Evals Course — AI evals course.

    Chapters: 00:00 Meet the Team; 01:18 Why Everyone Wears Product; 02:32 What Musubi Builds; 04:51 AI for Human Moderation; 09:59 Adversaries and Asymmetry; 11:48 Early Days and Low Latency; 13:35 First Prototype Slice; 15:33 Traditional ML Meets LLMs; 19:52 Benchmarking Against Humans; 23:09 LLM as Judge and Policy Gaps; 29:53 From Prototype to Platform; 31:15 Customer Onboarding Reverse Demos; 36:08 Custom Models Per Customer; 38:05 Fine Tuning vs Training; 39:14 Embedding Driven Classification; 40:04 Cost and Latency Tradeoffs; 43:21 Productizing Customization; 49:16 Scaling Prototypes to Production; 51:58 Golden Sets and Policy Loops; 56:17 Coaching Customers Safely; 01:02:06 Gamified Feedback Signals; 01:06:19 Agentic Toolkit Roadmap; 01:09:05 Workflow Orchestration Future; 01:12:06 Wrap Up and Thanks.

    Ultimately, this is a playbook for modern trust and safety: align your models to your policies, make evals a habit not an event, and empower non-technical teams with agentic workflows and transparent metrics. That’s how we move beyond black-box scores to systems we can measure, manage, and trust.

    Inspired by this post on Product Talk.

    Book a consult png image
  • How Agentic Analytics Reshapes Product Development Roadmaps

    How Agentic Analytics Reshapes Product Development Roadmaps

    Agentic, analytics-driven product development changes the role of product data. Instead of waiting for teams to interpret dashboards and debate a backlog, an agent can help detect behavioral friction, estimate opportunities, propose interventions, and monitor whether a release improves the intended outcome.

    The practical payoff is not an automatically generated roadmap. It is a tighter decision system in which evidence, experiments, delivery controls, and human judgment reinforce one another. The two source articles approach that system from complementary angles: one describes the operating loop around Amplitude Wave, while the other emphasizes the engineering and organizational foundations required to make agentic recommendations dependable.

    The product agent is a decision loop, not a smarter dashboard

    Traditional analytics tools help teams inspect funnels, cohorts, journeys, activation, and retention. The article about Amplitude Wave describes a more proactive model: an agent continuously scans behavioral data for friction, proposes a next-best improvement, supports validation through A/B testing, and uses feature flags to control rollout. After launch, the loop continues by monitoring activation, retention, and downstream revenue rather than treating deployment as the finish line.

    The companion article makes a similar distinction between reporting and agency. It presents agentic systems as capable of proposing, testing, and learning, provided that recommendations remain connected to rigorous behavioral analytics. Synthesized together, the sources describe four linked functions: observation identifies where behavior diverges from an intended journey; prioritization weighs the size, risk, and confidence of an opportunity; experimentation tests whether a proposed change causes improvement; and monitoring determines whether to expand, revise, or retire that change.

    This framing matters because an agent that only generates feature ideas adds another opinion to roadmap planning. An agent that connects ideas to observed behavior, controlled tests, and post-release measurement can instead reduce the distance between a weak signal and a defensible product decision.

    Reliable recommendations depend on an analytics and evaluation stack

    Both sources put instrumentation ahead of automation. The Wave article calls for clearly defined events, models that connect those events to user and account journeys, explicit success metrics, and governance around data quality and privacy. Without that foundation, an agent can produce confident explanations from incomplete or misleading evidence.

    The second article extends the foundation into three technical capabilities. It advocates a unified analytics platform that brings quantitative behavior together with qualitative context, evaluation harnesses that test prompts, policies, and models for regressions, and a retrieval-first pipeline that grounds an agent in trusted organizational information. These layers address different failure modes: analytics establishes what users did, retrieval supplies relevant business context, and evaluations test whether the agent behaves reliably as its components change.

    Interoperability broadens the evidence available to the system. The Wave article points to CRM integration, session replay, and support systems as useful connections for relating product behavior to customer value and go-to-market effects. CI/CD, experimentation tools, and feature flags then connect analysis to controlled delivery. The resulting architecture is less a standalone AI feature than a chain of evidence and controls spanning discovery, development, release, and measurement.

    That chain also establishes a sensible boundary for automation. Behavioral correlations may justify investigation, but they do not by themselves establish causality. A/B testing can provide stronger causal evidence when it is appropriate and well designed; qualitative context can explain why a pattern may be occurring; and human review can catch strategic, ethical, or operational considerations that product telemetry does not represent.

    Roadmaps become portfolios of measurable opportunities

    When agents can surface evidence-backed opportunities, roadmap discussions can move away from ranking requested features in isolation. The unit of planning becomes an outcome-linked opportunity: a behavioral problem, the users or accounts affected, the metric expected to move, the evidence supporting the hypothesis, and the safest way to test it.

    This does not eliminate product strategy. It makes strategy more explicit. Teams still decide which customers and outcomes matter, what constraints apply, and which trade-offs are acceptable. The agent can help maintain a current view of behavioral evidence and shorten the analysis cycle, but it cannot derive organizational priorities from telemetry alone.

    The sources also connect this operating model to empowered product teams, product trios, continuous discovery, and outcomes-versus-output OKRs. In that environment, an agent is best treated as a participant in the discovery and delivery workflow: it can surface anomalies, assemble relevant context, suggest hypotheses, and track results, while the team remains accountable for framing the problem and authorizing consequential decisions.

    The Wave article illustrates the intended scale of intervention with an onboarding example. It reports that an agent identified drop-off around a confusing configuration step; targeted in-app guidance and tooltips were then released behind feature flags, followed by a material improvement in activation with limited engineering effort. The report is a useful illustration of the loop, but it provides no numerical effect size or independent validation. It therefore supports the workflow concept more strongly than any general claim about expected results.

    Governance determines how much autonomy an agent earns

    Automation should expand according to demonstrated reliability and the reversibility of the action. Early implementations can begin in an advisory role, identifying friction and preparing evidence for a team to review. A later stage can allow the agent to configure draft experiments or recommend feature-flag settings. Direct changes to production warrant a higher threshold because errors can affect customers, revenue, privacy, and trust.

    The Wave article explicitly calls for policies governing data use, review thresholds for automated changes, privacy-by-design, and human checkpoints for high-impact decisions. The engineering-focused article complements those controls with eval-driven development, including tests intended to detect reliability and safety regressions across prompts, policies, and models. Together, these ideas suggest that autonomy should be earned through observable performance rather than granted because an agent appears persuasive.

    A practical adoption sequence follows from the synthesis. First, define the outcome and the decisions the agent may inform. Next, verify event quality and journey models before asking the system to prioritize opportunities. Then connect recommendations to a controlled experimentation and release process. Finally, evaluate both product impact and agent behavior, expanding permissions only when the evidence supports it. This sequence keeps the initial scope narrow while creating a path toward a more capable product-development system.

    Key takeaways

    • An agentic product workflow should connect behavioral observation, opportunity prioritization, experimentation, controlled delivery, and post-release measurement.
    • High-quality event data is necessary but insufficient; grounded retrieval, qualitative context, and evaluation harnesses make recommendations more dependable.
    • Roadmaps become more evidence-driven when teams plan around measurable opportunities rather than treating feature requests as predetermined commitments.
    • Human judgment remains essential for strategy, causal interpretation, risk assessment, and high-impact release decisions.
    • Agent autonomy should increase only as evaluations, governance controls, and observed performance justify broader permissions.

    The near-term opportunity is to build a disciplined learning loop before pursuing full autonomy. Organizations that make their data trustworthy, their outcomes explicit, and their release controls measurable will be better positioned to let product agents take on more consequential work without weakening accountability.

    References

  • AI Agent Product Development: From Workflow to Autonomy

    AI Agent Product Development: From Workflow to Autonomy

    AI agent product development is not primarily a model-selection exercise. It is the work of turning a business outcome into a bounded system that can retrieve information, use tools, make decisions, and escalate safely.

    The practical payoff comes from sequencing those capabilities carefully. A focused workflow, explicit measures, controlled access, and continuous evaluation provide a more credible path to value than attempting broad autonomy at launch.

    Key takeaways

    • Define the business outcome and proof of success before choosing prompts, models, or tools.
    • Begin with a repeatable workflow whose inputs, outputs, and failure conditions can be judged clearly.
    • Increase capability in stages: relevant retrieval, limited tools, read-only integrations, controlled actions, and then broader autonomy.
    • Treat privacy, governance, evaluation, observability, and human escalation as product requirements from the beginning.
    • Scale only when operational quality and the intended business outcome remain stable in production.

    Start with a decision contract, not an agent concept

    An agent initiative becomes testable when the team can state what decision or task the system will handle, what information it requires, what it must never do, and how success will be measured. This creates a decision contract between the product, its users, and the organization operating it.

    The supplied source recommends anchoring an AI strategy to one measurable outcome before writing a prompt or selecting a model. It gives lead response time, first-contact resolution, and time-to-first-value as possible measures. Those examples illustrate an important distinction: the agent is a means of changing workflow performance, not the outcome itself.

    This framing also makes AI readiness concrete. Instead of asking whether an organization is generally ready for agents, a product team can examine one workflow: Is the required data available? Are the inputs sufficiently consistent? Can acceptable output be recognized? Are the constraints and escalation conditions explicit? A negative answer identifies product work to complete; it does not automatically call for a more capable model.

    A useful initial scope therefore has clear boundaries and frequent enough repetition to produce evidence. The source identifies support-ticket triage, inbound-lead qualification, and account-note summarization as examples. Their significance is not that every organization should adopt them, but that they offer observable inputs and outputs. That makes errors easier to classify and improvements easier to evaluate.

    Design capability as an autonomy ladder

    The core architectural question is not whether an agent can perform an action. It is what evidence should be required before the product is allowed to perform that action without review. Treating capability as an autonomy ladder gives the team intermediate states between a passive assistant and an unrestricted operator.

    The source proposes a retrieval-first pipeline that introduces only relevant knowledge into the context window. In product terms, retrieval is part of the experience contract: the system should receive the information needed for the task without being burdened by unrelated material. This can improve the conditions for relevant responses, although retrieval does not eliminate the need to evaluate the final behavior.

    Tool access should be similarly bounded. The source recommends a small, explicit tool catalog, with the agent’s role, constraints, and escalation routes documented. It also points to Model Context Protocol as a way to standardize tool invocation across services. Standardization can make integrations more consistent, but it does not decide which tools the agent should receive or what permissions those tools should carry; those remain product and risk decisions.

    Systems of record deserve special caution. The source advises beginning with read-only CRM integration and adding actions only after reliability has been demonstrated. This suggests a practical progression: first observe and recommend, then prepare an action for approval, and only later execute eligible actions within defined limits. Each step creates new failure consequences, so each should have its own evidence threshold.

    Prompt engineering belongs inside this broader capability design. A prompt can express the agent’s role and boundaries, but predictable operation also depends on retrieved context, tool definitions, permissions, timeouts, escalation logic, and the surrounding user experience. Managing only the prompt would leave much of the product’s actual behavior outside the team’s control.

    Make trust an executable product requirement

    Agent risk becomes manageable when broad principles are translated into system behavior. Privacy-by-design should affect what data enters the workflow. Data governance should determine which sources and actions are permitted. Human oversight should appear as an explicit escalation path rather than an informal promise that someone can intervene.

    The source calls for regression evaluations covering safety, accuracy, and bias, alongside logs of agent actions, rate limits, timeouts, and risk scoring for high-impact operations. Together, these controls form a layered safety model. Evaluations test expected behavior before and during release; operational limits constrain runtime exposure; logs support diagnosis and accountability; and risk gates determine when automation must stop or seek approval.

    Uncertainty should also have a designed destination. According to the source, the default response for high-stakes or uncertain situations should be human escalation. A useful handoff needs more than a generic error message: the receiving person should be able to understand the request, the context used, the action considered, and why the system declined to continue. Handoff quality is therefore part of the product experience as well as the risk model.

    This approach avoids treating guardrails as a final compliance checkpoint. When controls are defined alongside workflow requirements, they influence architecture, permissions, interface design, analytics, and release criteria. Trust then becomes something the team can test and operate, rather than a claim attached to the launch.

    Use two evidence loops to decide when to scale

    An agent can appear technically competent without improving the business outcome that justified it. Product development therefore needs two connected evidence loops: one for operational quality and another for workflow impact.

    For operational quality, the source recommends monitoring precision, latency, containment, and handoff quality through agent analytics. These measures answer different questions. Precision concerns whether outputs or decisions are correct enough for the task. Latency affects whether the agent fits the pace of the workflow. Containment indicates how often work remains within the automated path. Handoff quality examines whether escalation preserves context and enables a productive recovery.

    The business loop returns to the original outcome, using outcomes-versus-output OKRs to avoid equating shipped features with value. A team might improve a prompt, add a tool, or increase containment while leaving the target workflow unchanged. That is useful diagnostic progress, but it is not yet evidence that the product investment is working.

    The source also recommends A/B testing prompts and tools and considering minimum detectable effect when sizing experiments. Experimentation is most informative when the changed component, eligible population, success measure, and guardrails are defined in advance. Otherwise, movement in a downstream metric can be difficult to attribute to the agent change.

    Qualitative learning completes the loop. The source describes product trios spanning product management, design, and engineering, supported by continuous discovery, weekly transcript review, and the conversion of failure modes into test cases. It also recommends keeping prompts, tools, and evaluations versioned through a docs-as-code approach. This connects discovery to engineering discipline: observed failures become reproducible evaluations, evaluated changes become versioned releases, and releases can be compared or reversed.

    Scope and autonomy should expand only when both loops support the decision. Stable technical metrics without workflow impact suggest that the use case or experience needs reconsideration. Business improvement accompanied by unsafe or unreliable behavior suggests that scaling is premature. Evidence across both dimensions supports a measured move into adjacent tasks or higher-impact actions.

    Build the next release around earned autonomy

    The durable pattern for AI agent products is earned autonomy: every increase in access or authority follows evidence from a narrower operating state. As evaluations accumulate and real workflow performance becomes visible, teams can make expansion decisions based on demonstrated capability rather than the apparent fluency of a demo.

    References

  • From AI Builder to Agent Swarm: A Product Delivery Model

    From AI Builder to Agent Swarm: A Product Delivery Model

    AI-native product delivery has two distinct layers: a product professional who turns uncertainty into testable artifacts, and an agent workflow that divides complex work among specialized AI components. Treating either layer as the whole model misses the more useful opportunity.

    Together, the AI Builder role described by Product School and the parallel-agent architecture discussed by Pendo suggest an operating model for moving from customer evidence to evaluated software. The central lesson is not simply to add more AI. It is to assign clear responsibilities, preserve evidence across handoffs, and expand automation only where it improves a measurable constraint.

    Key takeaways

    • The AI Builder is the human integration layer, connecting discovery, prototyping, evaluation, and delivery inside the product trio.
    • Parallel agents are a system design choice, useful when specialized paths can improve latency, answer quality, or resilience.
    • Evaluations, analytics, observability, and controlled releases form the shared control system for both layers.
    • Fan-out should respond to uncertainty and business importance rather than becoming the default for every task.

    One delivery system, with human and machine responsibilities

    The Product School article presents the AI Builder as a hybrid product professional rather than a renamed product manager or an isolated prototyper. In its account, this person uses AI across analysis, prototyping, evaluation, and shipping, with the aim of shortening the distance between a customer problem and a runnable experiment.

    The Pendo article addresses a different layer. It describes workflows in which research, reasoning, tool use, and formatting can be assigned to specialized agents and then reconciled. Its focus is not ownership of the product problem, but the computational structure used to complete work.

    Read together, the articles separate two ideas that are often blurred. An AI-native team still needs a person or group to choose the problem, define acceptable behavior, interpret customer evidence, and decide whether an experiment justifies investment. Agents can perform bounded tasks within that process, but parallel execution does not establish product relevance on its own.

    LayerPrimary responsibilityTypical artifactsControl question
    AI Builder and product trioTranslate customer and business uncertainty into experimentsPrototypes, evaluation criteria, instrumented experiences, delivery recommendationsIs the team learning about an outcome that matters?
    Agent workflowExecute and reconcile specialized tasksRetrieved context, candidate responses, tool results, rankings, formatted outputsDoes orchestration improve the target measure enough to justify its complexity?
    Delivery platformProvide access, measurement, release controls, and safeguardsTool interfaces, traces, feature flags, budgets, analytics, fallbacksCan the workflow be observed, governed, and changed safely?

    This division of responsibility also clarifies the meaning of vibe coding in the Pendo account. Prompts, examples, and constraints are used to shape an intended experience before the team commits to extensive code or rigid rules. The AI Builder supplies the product judgment and experiment design around that activity; an agent architecture supplies one possible execution mechanism.

    Parallelism should target a constraint, not become a default

    Pendo reports three proposed benefits of parallel agents. Independent specialists can work concurrently to reduce latency, diverse candidate paths can be compared to improve quality, and risky or failure-prone operations can be isolated behind fallbacks. The article names fan-out/fan-in, race-and-rerank, specialist swarms, consensus, and self-consistency checks as patterns for producing and reconciling candidates.

    Those benefits depend on the shape of the task. Parallel research may help when several sources or interpretations must be examined independently. A race-and-rerank pattern may help when multiple plausible outputs can be scored against explicit criteria. Guarded fallbacks may improve resilience when a tool can fail without invalidating the entire experience. By contrast, multiplying agents around a simple, deterministic step adds coordination, cost, and more places to inspect when something goes wrong.

    The Product School article provides the missing selection mechanism: the workflow begins with a high-signal use case and explicit evaluation criteria. That makes orchestration a response to observed limitations in an experiment rather than an architectural commitment made in advance. A prototype can begin with the smallest credible workflow, reveal whether the bottleneck is grounding, reasoning, tool reliability, or response time, and introduce specialization at that point.

    Pendo proposes a similar progression at the system level: begin with retrieval, add a planner-executor split, and introduce parallel specialists where accuracy or latency problems appear. It also recommends placing budgets on fan-out, caching results, using smaller models when confidence is high, and widening the workflow when uncertainty rises. These are recommendations from the source, not independently reported benchmarks, but they establish a useful product principle: additional computation should be purchased in proportion to uncertainty and consequence.

    Evaluation is the bridge from discovery to dependable delivery

    The strongest overlap between the two articles is evaluation. Product School describes AI Builders converting interviews and behavioral analytics into instrumented experiments, benchmarking quality before production, and using A/B testing to feed results back into strategy. Pendo similarly calls for offline evaluations before rollout, production experiments afterward, and agent-level analytics to identify regressions across individual workflow steps.

    This creates a continuous evidence path rather than a handoff between discovery and engineering. A customer problem informs a prototype; the prototype produces evaluation cases; those cases become release gates; production behavior supplies new evidence for the next iteration. CI/CD can move changes through the delivery system, while evaluations determine whether an AI behavior is ready to move with them.

    A staged adoption path

    1. Select a bounded use case. Product School suggests beginning with a high-signal application such as generative-AI prototyping or an in-app guide, rather than attempting to transform the whole delivery process at once.
    2. Define the evidence before expanding the build. Specify evaluation criteria, analytics, and the customer or business outcome the experiment is intended to illuminate.
    3. Establish grounded context. Both articles emphasize retrieval-oriented workflows. Product School also discusses prompts, context windows, and data contracts as product surfaces that require deliberate design.
    4. Start with minimal orchestration. A single workflow or planner-executor arrangement provides a baseline against which a specialist or parallel design can be judged.
    5. Add parallel paths selectively. Introduce research, tool-calling, reasoning, or validation specialists only where evaluation results reveal a material limitation.
    6. Release behind controls. The sources point to feature flags, A/B testing, observability, anomaly detection, fallbacks, and post-launch review as ways to expose failures and limit their impact.

    The Model Context Protocol appears in both accounts as a way to standardize access to tools and data. Product School frames MCP integrations as part of an AI Builder’s toolbox, while Pendo argues that standardized access keeps agent roles separate from authentication, quotas, and observability. The combined implication is organizational as well as technical: shared interfaces can let product teams experiment with workflow roles without embedding every platform concern in every prompt.

    The operating model changes what a product team owns

    Product School places the AI Builder inside the product trio, working with design and engineering from the beginning. Pendo argues that product trios can own complete AI workflows rather than limiting their attention to prompts. These views converge on broader product accountability: the team owns the behavior, evidence, cost, risk, and release mechanism as one product surface.

    That ownership requires clearer boundaries, not fewer disciplines. Product judgment determines which outcome deserves attention. Design shapes the customer interaction and failure experience. Engineering and platform work make tool access, observability, quotas, and release controls dependable. The AI Builder connects these concerns through runnable artifacts, while specialized agents remain replaceable components within the evaluated workflow.

    The resulting measure of maturity is not the number of agents deployed or the speed of prototype generation. It is whether the team can trace a customer need through an experiment, an evaluation, a controlled release, and a learning decision. As tools become easier to compose, that chain of evidence will be the durable advantage in AI-native product delivery.

    References

  • Engineering MCP Agents as a Reliable Product Platform

    Model Context Protocol adoption becomes consequential when an agent can retrieve organizational knowledge, select tools, and change a system of record. At that point, the engineering challenge is no longer simply connecting a model to an API. It is operating a product platform whose context, permissions, decisions, and side effects must remain dependable.

    The source article’s experience with workflows spanning Miro, Jira, and Confluence points to a coherent platform model: retrieval determines what the agent knows, tool contracts constrain what it can do, evaluation tests its behavior, and observability makes failures diagnosable. Product strategy and interaction design then determine whether that machinery improves work users already perform.

    Key takeaways

    • Treat retrieval, tool schemas, prompts, policies, and telemetry as platform components with explicit owners and versioning.
    • Prove one frequent, measurable workflow before expanding the agent’s tool and use-case surface.
    • Combine least-privilege access with visible tool rationale, consent controls, audit records, and safe recovery paths.
    • Evaluate the complete chain from retrieved context to downstream action, not just the quality of generated text.
    • Govern the tool catalog and delivery pipeline continuously so that extensibility does not become uncontrolled operational risk.

    The platform boundary extends beyond the MCP connection

    MCP provides a practical interface through which models can reach data, tools, and actions, according to the source article. The protocol connection is therefore an enabling layer, not the whole agent platform. A production workflow also depends on source authority, identity and permission checks, context selection, tool arbitration, execution controls, user-facing recovery states, and evidence that the result was useful.

    This broader boundary changes how teams should decompose the system. Retrieval is a managed context service rather than an incidental prompt-building step. Tools are governed capabilities rather than a loose collection of endpoints. Prompts and policies are deployable artifacts rather than text copied into application code. Traces and evaluations are part of the control plane because they reveal whether the other layers continue to work together.

    The source recommends starting with authoritative content, normalizing it with docs-as-code discipline, attaching metadata that supports permission-aware filtering, and selecting the smallest high-signal context needed for a task. The engineering implication is important: access control must shape retrieval before information reaches the model. Filtering only when an action is attempted would leave the reasoning process exposed to context the user or agent may not be entitled to use.

    Context quality also affects more than answer accuracy. The source links focused retrieval to lower hallucination risk, more accurate tool calls, and lower cost. That makes retrieval performance a shared dependency for safety, reliability, latency, and economics. It deserves its own contracts, tests, freshness expectations, and failure modes.

    A golden path turns architecture into an operating contract

    The source describes an initial workflow that summarized a Miro board into action items and wrote them to Jira. It reports that variants involving Confluence summaries, epic splitting, and backlog grooming followed only after the original path reached its reliability targets. This is less a recommendation for those particular products than a useful sequencing principle for agent platform engineering.

    A narrowly defined workflow exposes the entire contract between context and consequence. The team must decide which content is authoritative, what the model may infer, which tool is appropriate, what inputs the tool accepts, what the user should review, how a partial failure is handled, and how success is measured. A broad assistant can conceal these questions behind plausible conversation; a golden path forces explicit answers.

    The right first workflow is therefore not merely technically convenient. It should be frequent enough to matter, have an observable completion state, and carry side effects that can be bounded. The source frames outcomes such as time saved during backlog grooming, better meeting notes in Confluence, and fewer context switches across Miro boards as more useful roadmap anchors than novel model capabilities. It also recommends comparing task success, completion time, user edits, detected defects, and downstream business effects rather than relying on engagement alone.

    Those measures form a practical evidence chain. Evaluation results show whether the system behaves as designed; workflow measures show whether users can complete the task; business measures show whether the completed task creates value. Keeping the levels distinct prevents a technically impressive agent from being mistaken for a successful product.

    Safety depends on controlling actions and explaining them

    Tool access creates a sharper risk boundary than text generation because an incorrect decision can alter a ticket, document, or other shared record. The source’s proposed response combines least-privilege scopes, a human-readable rationale for each call, and an audit trail. It also calls for proposed inputs and expected side effects to be visible when the agent is about to use a tool.

    These controls address different failure classes. Narrow scopes limit the maximum effect of a bad decision. Input previews help users catch incorrect parameters before execution. Rationale makes the selection inspectable. Audit records support diagnosis and accountability afterward. None substitutes for the others, and a confirmation dialog alone does not make an overprivileged tool safe.

    Recovery behavior belongs in the same design. The source recommends retrying suitable failures with backoff, falling back to read-only behavior, or requesting consent or missing context. A robust platform should distinguish failures that are safe to retry from failures that require a different plan. It should also preserve an understandable state when a multi-step workflow completes only partially, so the user knows what changed and what did not.

    Transparency need not mean exposing raw internal reasoning. The useful product surface is operational evidence: the sources used, the selected capability, the intended inputs, the expected effect, and the resulting status. The source suggests a reveal panel containing retrieved sources, candidate tools, and confidence signals for power users. More generally, the amount of review should follow the consequence of the action: low-risk retrieval can remain lightweight, while consequential writes warrant clearer inspection and consent.

    Evaluation, observability, and delivery form one reliability loop

    The source outlines offline tests for intent classification and tool selection, online shadow evaluations for live drift, and regression checks after deployment. It also recommends traces that capture prompts, retrieved chunks, tool inputs, tool outputs, latency, and error codes. Together, these practices connect a visible failure to the component and version that produced it.

    Evaluation without observability can show that quality declined without explaining why. Observability without evaluation can produce detailed traces without deciding whether the behavior was acceptable. A mature loop needs both: test cases encode desired behavior, traces expose actual behavior, and production outcomes reveal gaps in the test set.

    The delivery process must preserve that connection. The source treats prompts, tool schemas, and guardrails as versioned artifacts deployed behind feature flags, with canary releases, controlled comparisons, and rollback capability. This approach makes a behavioral change attributable. If tool selection deteriorates after a prompt revision or a schema update breaks an integration, operators can identify the change and contain its reach.

    Latency should be governed in the same loop because an accurate workflow can still fail as a product experience. The source reports using task-specific latency budgets, caching stable retrieval results, parallelizing safe calls, prefetching likely session context, and providing progress when work exceeds the expected budget. These techniques should remain subordinate to correctness: parallel execution is appropriate only when calls are independent, while caching must respect freshness and permission boundaries.

    The source also assigns prompts a user-experience role, combining plain-language intent, domain constraints, and explicit tool contracts while using examples, tooltips, and in-product guidance to help users frame requests. This connects conversation design to reliability. Better instructions can reduce ambiguity before the platform has to resolve it through additional model turns or risky assumptions.

    Scale requires governance of tools, teams, and ownership

    MCP’s extensibility can turn into tool sprawl if every integration is added without lifecycle management. The source recommends a curated catalog recording each tool’s owner, scope, schema version, and deprecation policy. It also describes schema linting in continuous integration, backward-compatible changes, and quarterly retirement of unused tools. These are conventional platform disciplines applied to an agent’s capability surface.

    A catalog is valuable because an agent reasons over descriptions and schemas while operators depend on stable implementation contracts. Poorly differentiated tools can make selection ambiguous; unannounced schema changes can invalidate prompts and evaluations; ownerless tools can remain available after their data or permission assumptions have changed. Governance should therefore assess semantic clarity as well as API validity.

    Organizational design matters for the same reason. The source describes an empowered trio consisting of a product manager responsible for outcomes and risk posture, a forward-deployed engineer focused on schemas and scalability, and a designer responsible for conversational flows and recovery states. It also favors weekly evaluation reviews over demonstration-led progress. The underlying principle is shared ownership: platform reliability cannot be delegated entirely to model engineering when the decisive questions span product value, system behavior, permissions, and user comprehension.

    The source’s proposed 30-day starter sequence moves from selecting one workflow and defining permissions, measures, and evaluations; through retrieval and a minimal tool set; to an instrumented internal pilot; and finally to hardening and a limited beta. The schedule is reported as a blueprint rather than independent proof of how long every implementation should take. Its more transferable lesson is dependency order: define the outcome and risk boundary before multiplying capabilities.

    As agents begin coordinating across products, the durable advantage will come from platforms that preserve this discipline across every new connection. MCP can make capabilities composable, but dependable composition will still depend on controlled context, explicit authority, observable execution, and evidence that the workflow improves real work.

    References

  • Reusable AI Agent Workflows Need Evaluation Contracts

    Reusable AI Agent Workflows Need Evaluation Contracts

    Reusing an AI agent capability can accelerate delivery, but reuse also multiplies the consequences of an undetected defect. A retrieval component, tool-call routine, or safety check may appear in several workflows, so its quality cannot depend on the team that happens to integrate it next.

    The practical answer is to package each reusable skill with an evaluation contract: defined behavior, test fixtures, observability, guardrails, and outcome measures that travel with the component. Read together, the two source articles outline how modular workflow design and eval-driven development can reinforce each other from prototype through production.

    Reuse requires a contract, not just a prompt

    The AI skills library article describes modular capabilities for retrieval and grounding, summarization, classification, tool use, data enrichment, safety controls, and evaluation harnesses. Its central architectural idea is consistency: common interfaces and conventions allow teams to compose capabilities and replace implementations without rebuilding an entire flow.

    That modularity addresses code and workflow reuse, but it leaves an important product question: what must remain true when an implementation is replaced? The product-manager evaluation playbook supplies the missing half. It calls for versioned prompts, tools, and datasets; fixed offline scenarios; production experiments; and traces that expose how an agent reached an answer.

    The synthesis is an evaluation contract attached to every reusable skill. The contract defines acceptable inputs and outputs, relevant policies, expected telemetry, representative tests, and promotion thresholds. A skill is then reusable because its behavior can be checked repeatedly, not merely because its code can be imported.

    This distinction matters most in composed workflows. A summarizer that performs well on clean text may behave differently after a weak retrieval step. A tool-use component may generate a plausible response even when the underlying action fails. Reusable interfaces make these components interchangeable; evaluation contracts make the substitutions accountable.

    Measure four layers of agent quality

    No single score can represent the quality of a reusable agent workflow. The evaluation article separates concerns such as task success, factuality, safety, latency, cost, evidence quality, and product outcomes. The skills-library article adds operational concerns around guardrails, runtime metrics, and production monitoring. Combined, they suggest a four-layer model.

    Evaluation layerQuestion it answersReusable evidenceReported signals
    Component behaviorDoes the skill perform its assigned task?Fixed fixtures, golden examples, and domain scenariosTask success, factuality, and retrieval evidence quality
    Safety and policyDoes it remain within required boundaries?Adversarial cases, policy checks, and guardrail configurationsSafety performance, PII handling, and content-policy adherence
    Operational performanceCan it run reliably within product constraints?Traces, logs, version records, and production dashboardsLatency, cost, tool success, and fallback behavior
    Product impactDoes better agent behavior create user or business value?Experiment definitions and driver-tree mappingsTask completion, satisfaction, activation, retention, and NRR

    The layers should remain distinguishable even when a dashboard brings them together. If a workflow’s task-success score rises while latency or cost deteriorates, the trade-off should be visible. If offline factuality improves without changing completion or satisfaction in production, the result should not automatically be treated as a product win.

    Retrieval-first workflows illustrate the value of separation. The evaluation playbook recommends assessing the quality of retrieved evidence independently from generation. That boundary makes a failure attributable: the system can distinguish missing or irrelevant evidence from a generator that mishandled useful context. The same principle applies to classification, tool selection, tool execution, and response composition.

    A reusable workflow needs a controlled promotion path

    The two sources describe complementary stages rather than competing evaluation methods. The skills-library article starts with a quick-start chain, configurable skills, guardrails, evaluation datasets, and instrumentation. The evaluation playbook places fixed offline suites before user exposure, followed by controlled online validation. Together they form a promotion path from composable prototype to measured production capability.

    Offline evaluation establishes eligibility

    A candidate workflow should first face stable examples representing core scenarios, known failure modes, edge cases, adversarial prompts, and domain-specific questions, as reported by the evaluation playbook. Stable fixtures make comparisons reproducible when a prompt, model, tool, retrieval strategy, or policy changes. Running these checks through CI/CD, as proposed in the skills-library article, turns evaluation into a regular release control instead of a separate audit.

    Model-based judges can expand coverage for qualities such as helpfulness, coherence, and adherence, but the evaluation article cautions that they require calibration against a small, high-quality human-labeled set. It also recommends monitoring judge drift and retaining human review for edge cases or flows where mistakes carry greater consequences. A reusable judge configuration should therefore include its rubric, reference labels, version, and conditions for escalation.

    Online evaluation establishes value

    Passing offline checks shows that a variant is eligible for controlled exposure; it does not prove that users benefit from it. Both articles describe feature flags and A/B testing as mechanisms for comparing workflow variants in production. The evaluation playbook identifies conversation outcomes, tool success rates, human-support fallbacks, and user satisfaction as useful online signals.

    This staged approach also limits ambiguity. An offline regression can block a weak component before exposure, while an online experiment can test whether an eligible improvement changes real behavior. Promotion should depend on both: acceptable component performance and evidence that the complete workflow advances its intended outcome.

    Traces turn composition failures into fixable problems

    Composability increases the number of boundaries at which a workflow can fail. The evaluation playbook treats traces as the backbone of agent evaluation because they record inputs, intermediate actions, invoked tools, and final responses. The skills-library article similarly connects reusable chains to logs, traces, metrics, and production dashboards.

    A final-answer score alone may reveal that a workflow failed, but a trace can localize the failure. It can show whether retrieval supplied poor evidence, classification selected an unsuitable route, a tool call failed, a guardrail intervened, or generation ignored valid context. This makes evaluation useful for component ownership: teams can repair the relevant skill rather than adding a broad prompt patch to the entire chain.

    Trace analysis also supports reuse decisions. If one component repeatedly causes latency, cost, or safety regressions across several workflows, improving that shared component may create more value than optimizing each application independently. Conversely, a component that succeeds in one context but fails in another may need a narrower contract rather than a universal interface.

    Versioning is essential to that diagnosis. The evaluation playbook recommends versioning prompts, tools, and datasets, while the skills-library article emphasizes swappable implementations and comparable variants. Without linked versions for the component, evaluation set, judge, and workflow configuration, an apparent improvement may be difficult to reproduce or attribute.

    Governance and product outcomes belong in the same system

    Reusable workflows can spread good controls, but they can also propagate weak ones. The skills-library article reports guardrails for PII redaction, content-policy checks, and rate limiting, alongside configuration intended to support privacy-by-design. Packaging these controls as reusable capabilities can make the approved path easier to adopt, while evaluation fixtures test whether the controls continue to work as surrounding workflows change.

    Governance should not be reduced to a final pass-or-fail gate. Safety, privacy, and policy behavior need their own cases and traces throughout development. The amount of human review can then reflect the cost of error, consistent with the evaluation playbook’s recommendation to retain human oversight for higher-risk flows.

    The same evaluation system must connect technical quality to product value. The evaluation playbook proposes a driver tree that links per-turn measures such as helpfulness, safety, and latency to session outcomes such as task completion, and then to product measures including activation, retention, and Net Recurring Revenue. This hierarchy prevents a local metric from becoming the objective by default.

    For product teams, the resulting unit of roadmap work is not simply a new skill. It is a versioned capability with evidence about behavior, operational fitness, policy compliance, and contribution to an intended outcome. That shared definition gives product trios, engineers, and governance stakeholders a more precise basis for deciding whether to reuse, revise, or retire a component.

    Key takeaways

    • Package each reusable agent skill with an evaluation contract covering behavior, fixtures, telemetry, policies, and promotion criteria.
    • Keep component quality, safety, operational performance, and product impact distinct so improvements and trade-offs remain attributable.
    • Use fixed offline evaluations to establish release eligibility, then controlled online experiments to determine real-world value.
    • Trace intermediate steps and tool activity so failures can be assigned to the correct component instead of patched at the final response.
    • Version workflows, prompts, tools, datasets, and judges together so results remain comparable and reproducible.

    As skill libraries expand, their lasting advantage will come from accumulated evidence rather than component count. Teams that make evaluation portable alongside implementation can reuse workflows without surrendering visibility, governance, or product accountability.

    References