# Viswas Vuppala Source URL: https://viswas.dev/ Viswas Vuppala / GenAI product leader # I turn emerging GenAI capabilities into useful, trustworthy products. I connect customer and developer needs with technical judgment, cross-functional leadership, and hands-on experimentation—from early idea to accountable product decisions. - [Software](https://viswas.dev/software) — Agent and product systems - [Hardware](https://viswas.dev/hardware) — Offline and safety-bounded - [Career](https://viswas.dev/career) — Roles, scope, and skills - [Knowledge](https://viswas.dev/knowledge) — Frameworks and methods - [Beyond Work](https://viswas.dev/beyond-work) — Kova, golf, poker, and AI Ready RVA ## 01 / Overview ## From ambitious GenAI ideas to products people can trust and teams can execute. I translate customer and developer needs into strategy, roadmaps, technical requirements, evaluation plans, and product decisions that cross-functional teams can execute. ### Operating center ### 0→1 GenAI Product Leadership - Product strategy: Customer and developer needs into product theses and roadmaps. - Context and systems: Model capabilities and constraints into requirements and workflows. - Evaluation and trust: Observable quality, failure modes, and release decisions. - Cross-functional leadership: Product, engineering, design, data science, research, risk, legal, and operations. - Hands-on building: Prototypes, APIs, data, and modern AI development tools. - [Review software](https://viswas.dev/software) - [Review career](https://viswas.dev/career) ## 02 / Selected proof ## Three ways I turn emerging capability into useful product systems. Each project makes the customer problem, product judgment, evidence, and current boundary visible. ### Helios AI-native product development / In development An in-development product context system that connects research, decisions, requirements, and delivery evidence so AI-assisted product work remains grounded and reviewable. Diagram: Research, decisions, and requirements converging into product context and an evaluation receipt. - RESEARCH - DECISIONS - REQUIREMENTS - PRODUCT / CONTEXT - EVALUATION / RECEIPT Case study coming soon ### FedAI Federal GenAI consulting / Founder-led practice Founder-led federal GenAI consulting focused on approved-source retrieval, privacy, guardrails, auditability, and the path from stakeholder discovery to technical deployment. Diagram: Approved sources moving through retrieval and guardrails into audit review. - APPROVED / SOURCES - RETRIEVE - GUARDRAILS - AUDIT / REVIEW Case study coming soon ### Zyner + Treaty Physical AI experiment / Concept A playful, pre-build Raspberry Pi rover concept with separate, safety-bounded ways to bring Kova a treat or provide an adult-authorized personal handoff. ![AI-generated pre-build concept of a compact wheeled rover with a protected camera, enclosed handoff bay, and separate treat cassette on a home workbench.](https://viswas.dev/zyner-treaty-concept-workbench.webp) AI-generated concept visualization · pre-build Case study coming soon - [All software](https://viswas.dev/software) - [All hardware](https://viswas.dev/hardware) ## 03 / Career + knowledge ## Innovative GenAI product leadership—and the ideas behind it. ### Career ### Enterprise-scale GenAI, context and grounding platforms, regulated product leadership, and founder-led 0→1 work. I have led enterprise GenAI and context-grounding products, shaped federal AI consulting work, built data and analytics experiences, supported public-sector modernization, and founded 0→1 software—translating emerging capability into decisions cross-functional teams can execute. - [Read the on-page résumé](https://viswas.dev/career) ### Knowledge ### How I apply GenAI to product management, agent experience, adaptive coordination, and physical systems. First-person arguments and practical methods grounded in product work and primary research. - [Read frameworks and methods](https://viswas.dev/knowledge) ## 04 / Beyond Work ## Kova, golf, poker, and AI Ready RVA. What keeps me active, reflective, connected to community, and comfortable making decisions with incomplete information. - Kova: Kova gets me outside, keeps me moving, and makes an ordinary day more fun. - Golf: Golf gives me a few quiet hours outside with friends and room to think. - Poker: Poker is one of my favorite ways to spend an evening with friends. - AI Ready RVA: I volunteer with AI Ready RVA’s Product & AI Cohort, helping product managers apply AI tools and practical best practices across the product development cycle. https://www.aireadyrva.com/cohorts/product-ai - [Meet the person beyond the product work](https://viswas.dev/beyond-work) ## 05 / Recruiter handoff ## The full portfolio, in Markdown. A one-to-one text version of the public site for recruiters and AI agents, with direct URLs to every deeper page. - [Open /llm.txt](https://viswas.dev/llm.txt) - [LinkedIn](https://www.linkedin.com/in/viswasv/) --- # Software Source URL: https://viswas.dev/software Selected work / Software / Four project briefs Product judgment / Evidence / Boundaries # Emerging AI capabilities shaped into useful, trustworthy products. A public view of the product judgments, experiments, and systems behind my work. Detailed case studies are coming soon; private implementation, data, and operating material remain behind the boundary. Helios, FedAI, AwardLens, and Chatter demonstrate different ways to frame decisions, evidence, and trust. ## Software projects ### Helios AI-native product development / In development An in-development product context system that connects research, decisions, requirements, and delivery evidence so AI-assisted product work remains grounded and reviewable. Diagram: Research, decisions, and requirements converging into product context and an evaluation receipt. - RESEARCH - DECISIONS - REQUIREMENTS - PRODUCT / CONTEXT - EVALUATION / RECEIPT Coming soon ### FedAI Federal GenAI consulting / Founder-led practice Founder-led federal GenAI consulting focused on approved-source retrieval, privacy, guardrails, auditability, and the path from stakeholder discovery to technical deployment. Diagram: Approved sources moving through retrieval and guardrails into audit review. - APPROVED / SOURCES - RETRIEVE - GUARDRAILS - AUDIT / REVIEW Coming soon ### AwardLens Decision-support prototype / Prototype A fixture-backed travel decision prototype for comparing availability, transfer paths, and points tradeoffs without presenting uncertain inventory as fact. Diagram: Travel options compared by confidence and points path. - OPTION CONFIDENCE - POINTS PATH - COMPARE Coming soon ### Chatter Adaptive agent coordination / Local prototype A local prototype for dependency-aware agent coordination: when peer work changes an active plan, the affected agent can verify what happened, adapt within its existing authority, and publish a reconciliation receipt. Diagram: Completed peer work affecting a dependency, causing scoped re-strategizing and a reconciliation receipt. - COMPLETED / PEER WORK - AFFECTED / DEPENDENCY - AGENT / RE-STRATEGIZES / WITHIN SCOPE - REVISED WORKING / CONTRACT + / RECONCILIATION / RECEIPT Coming soon --- # Hardware Source URL: https://viswas.dev/hardware Hands-on experiment / Hardware / Pre-build Playful physical AI / Safety-bounded control # A fun way to bring Kova a treat—or give myself one. Zyner + Treaty explores how perception and language can make a small rover useful while deterministic controls govern motion and dispensing. The image and system are pre-build concepts—not constructed, tested, or safety validated. ## Zyner + Treaty Concept / abstracted A playful, pre-build Raspberry Pi rover concept with separate, safety-bounded ways to bring Kova a treat or provide an adult-authorized personal handoff. ![AI-generated pre-build concept of a compact wheeled rover with a protected camera, enclosed handoff bay, and separate treat cassette on a home workbench.](https://viswas.dev/zyner-treaty-concept-workbench.webp) AI-generated concept visualization · pre-build Coming soon --- # On-page résumé Source URL: https://viswas.dev/career On-page résumé / Five roles / LinkedIn available Career / Innovative GenAI product leadership # Creative GenAI solutions, grounded in customer needs and built for real workflows. I translate customer and developer needs into strategy, technical requirements, evaluation plans, and product decisions that cross-functional teams can execute. My experience spans enterprise GenAI, federal consulting, data and analytics products, public-sector modernization, and founder-led 0→1 software. [Continue on LinkedIn](https://www.linkedin.com/in/viswasv/) ## Selected roles ## Product leadership across different stakes. ### Capital One ### Manager, Product Management - GenAI Servicing July 2025 - Present Leads product work for enterprise GenAI servicing, connecting customer and associate needs with grounded model behavior, platform priorities, evaluations, and governance in a regulated environment. - Turn regulated service workflows into roadmap priorities, grounded model behavior, and testable quality and safeguard requirements. - Lead delivery across engineering, design, data science, risk, legal, operations, and product; manage and mentor PMs. - Enterprise GenAI - Platform strategy - Grounding and evaluation - Regulated delivery ### FedAI ### Founder - Federal GenAI Consulting March 2024 - July 2025 Founded a federal GenAI consulting practice focused on privacy-preserving agentic workflows, retrieval, guardrails, auditability, and the technical path from discovery to deployment. - Translated stakeholder needs into product strategy and technical delivery for privacy-preserving, retrieval-backed agent workflows. - Connected approved sources, role-based access, guardrails, citations, auditability, and human review to deployment decisions. - Founder leadership - Agentic workflows - Privacy and guardrails - Technical deployment ### Capital One ### Senior Product Manager - B2B Data & AI Analytics December 2022 - March 2024 Led product development for enterprise data and AI analytics, turning complex data and model capabilities into clearer workflows for business users. - Led a B2B data and AI analytics platform that put model capabilities behind a no-code workflow. - Connected customer discovery, platform constraints, and cross-functional delivery from roadmap through iteration. - B2B platform strategy - Data and AI products - Customer discovery - Roadmap execution ### Federal Maritime Commission ### Solutions Manager December 2021 - December 2022 Led modernization work across legacy applications and helped define secure, cloud-ready paths for analyst and operational workflows. - Led agency-wide modernization from fragmented legacy workflows to secure, cloud-ready solutions. - Evaluated cloud, integration, security, and adoption tradeoffs with technical and operational stakeholders. - Public-sector modernization - Workflow integration - Cloud strategy - Security tradeoffs ### Steelbasis ### Co-Founder & VP of Product February 2020 - December 2021 Co-founded a B2B software product for vendor and contract workflows in real-estate development, moving from problem discovery through product delivery and customer learning. - Co-founded and led product for B2B vendor and contract workflows from discovery through delivery. - Worked directly with customers to turn document-heavy operations into a focused 0→1 product. - 0→1 product development - Founder-led discovery - B2B SaaS - Document workflows ## Technical + product skills ## Close enough to the work to make good tradeoffs. ### ai Systems - LLMs and agent workflows - Context engineering and RAG - Agent evaluations, guardrails, and provenance - Model deployment and MLOps ### product - 0→1 product strategy - Platform roadmaps and operating models - Customer and developer discovery - Cross-functional product leadership ### technical - Python, SQL, and React - AWS and GCP - Docker and Kubernetes - AI developer workflows: Codex, Claude Code, and Cursor - Figma and product delivery tooling ## Education + certification ## Engineering roots. Product judgment. - UC Berkeley Haas: Product Management Certification in AI & Machine Learning - Virginia Commonwealth University: B.S. Engineering Evidence routes - [Software cases](https://viswas.dev/software) - [Knowledge and methods](https://viswas.dev/knowledge) --- # Knowledge Source URL: https://viswas.dev/knowledge Original writing / Knowledge / Four essays GenAI product management / Agent experience / Physical AI # Ideas for building creative, useful, and accountable GenAI products. First-person arguments and practical methods grounded in product work and primary research. Written for direct evaluation without publishing proprietary operating material. ## Index ## Ideas worth evaluating directly. ### [Context Is Product Architecture: How Helios Builds Living Product Memory](https://viswas.dev/knowledge/context-is-product-architecture) Essay A public-safe look at how Helios connects research, decisions, requirements, delivery evidence, evaluation, and verified learning into living product memory. - Type: Essay - Length: 10 min read - [Read](https://viswas.dev/knowledge/context-is-product-architecture) ### [Agents Should Re-strategize When the Work Changes](https://viswas.dev/knowledge/chatter-adaptive-agent-coordination) Essay Why agent messaging is not enough—and how verified dependencies, scoped re-strategizing, revised working contracts, and reconciliation receipts can make parallel work more coherent. - Type: Essay - Length: 11 min read - [Read](https://viswas.dev/knowledge/chatter-adaptive-agent-coordination) ### [Your Next Customer Might Be an AI Agent](https://viswas.dev/knowledge/agents-are-customers) Essay A product framework for treating AI agents as a new customer persona across findability, understandability, usability, trust, and measurement—without losing the human user they serve. - Type: Essay - Length: 11 min read - [Read](https://viswas.dev/knowledge/agents-are-customers) ### [Physical AI Is a Hardware-Software Product](https://viswas.dev/knowledge/physical-ai-hardware-software-codesign) Essay What the pre-build Zyner + Treaty rover concept teaches about co-designing perception, interaction, mechanics, power, software, safety controls, and staged validation. - Type: Essay - Length: 11 min read - [Read](https://viswas.dev/knowledge/physical-ai-hardware-software-codesign) --- # Context Is Product Architecture: How Helios Builds Living Product Memory Source URL: https://viswas.dev/knowledge/context-is-product-architecture Knowledge index: https://viswas.dev/knowledge Essay public Field note · GenAI product systems The context that makes AI useful is not a larger prompt. It is a maintained product system that preserves why a decision was made, what teams agreed to build, what actually changed, and what the evidence taught us next. - Author: Viswas Vuppala - Type: Essay - Reading time: 10 min read ## Living product memory is not an archive Product teams already create plenty of context. It lives in interview notes, strategy documents, design decisions, requirements, tickets, experiments, release records, and the judgment of people who were in the room. The problem is not a lack of material. The problem is that the reasoning connecting those materials decays as work moves from discovery to delivery. I am building Helios around a different premise: product context should behave like living memory. A useful memory does more than store an artifact. It preserves the relationship between evidence, a decision, the work that decision authorized, and the outcome that followed. It can also show when an assumption has become stale or when new evidence should change the plan. This is a public-safe account of the product loop and the product judgment behind it. Helios is in development, and its private implementation, prompts, repositories, customer material, and internal evaluation data are intentionally outside this article. > The product does not need to remember everything. It needs to preserve the evidence and decisions that should govern what happens next. ## The loop begins with research and decisions—not generated prose In Helios, research is useful only when a team can connect it to a product question. A customer observation, market signal, technical constraint, or operational risk should retain enough provenance for someone to understand where it came from, who interpreted it, and whether it is still valid for the decision at hand. The next object is the decision. That distinction matters. Research may support several plausible directions; a roadmap requires an accountable choice. I want the product record to preserve the decision, the evidence that informed it, the alternatives that were declined, the owner, and the conditions that would justify revisiting it. This prevents a common GenAI failure mode: a model finds several relevant documents and synthesizes them into a smooth recommendation without knowing which material is authoritative or which tradeoff the team actually accepted. The model can assist with synthesis, but the product must make authority and decision state explicit. - Research keeps its source, scope, freshness, and relationship to the product question. - Decisions retain an accountable owner, rationale, alternatives, and revisit conditions. - Unresolved conflicts remain visible instead of being averaged into a confident summary. ## Decisions become requirements that preserve intent A decision is not executable until cross-functional teams can see what it changes. Helios treats requirements as a translation layer between product judgment and delivery: the user or customer outcome, the behavior the system should exhibit, the context and authority it needs, the failure states it must handle, and the evidence that will count as acceptable. That translation is where product leadership earns its keep. The goal is not to ask a model to generate a longer specification. It is to maintain a traceable line from the customer need and product thesis to the technical and operational choices the team must make. A requirement should be able to answer why it exists and which decision it implements. For GenAI work, I also include the non-happy paths early: missing or conflicting context, unsupported claims, unavailable tools, permission limits, low-confidence behavior, escalation, and the difference between proposing an action and verifying that it occurred. Those are product behaviors, not cleanup tasks after the demo succeeds. ## Delivery evidence must return to the product record Most product systems are optimized for one-way handoffs. Strategy becomes requirements, requirements become tasks, and tasks become code. The product record may say that work is complete without showing what changed in the system users will actually encounter. Helios is designed around a return path. Delivery evidence can include the implemented artifact, a test result, a changed interface, a verified environment identity, or another receipt from the authoritative system. The exact receipt varies by product; the stable requirement is that a claim of completion should not rest only on the agent or team narrating that it is done. Returning evidence lets product, engineering, design, data science, research, risk, legal, and operations review the same outcome against the decision that authorized it. It also makes drift visible. If implementation changed the original intent for a valid reason, that change should become a new decision—not a silent divergence embedded in the final product. > A completed task is workflow state. A verified product change is evidence. ## Evaluation is a product decision system Evaluation in Helios is not a single model score at the end of development. It begins when the team defines what good behavior means for a real product task. That may include supportedness, task usefulness, consistency with the approved decision, appropriate abstention, safe tool use, or whether a reviewer received enough evidence to act. I want evaluation results attached to the product context that produced them. When a result changes, the team should be able to ask whether the source changed, retrieval changed, the requirement changed, the model changed, or the evaluation itself exposed a missing product decision. Without that lineage, every failure becomes a generic model-quality debate. Evaluation receipts also improve release judgment. They help a team distinguish a plausible demo from behavior that is sufficiently grounded and observable for the intended audience. A failed evaluation can produce a narrower scope, a better escalation, a revised requirement, or a decision not to automate. Those are all legitimate product outcomes. - Define quality against the user task and decision—not fluency alone. - Separate source quality, context selection, reasoning, tool use, and verified outcome. - Keep the evaluation result connected to the requirement and product version it assessed. - Treat abstention, escalation, and scope reduction as designed outcomes when evidence is insufficient. ## Verified learning closes the loop A product memory becomes living when observed outcomes can change what the team believes. Customer feedback, production behavior, evaluation failures, and delivery constraints should not disappear into separate dashboards. The useful signal should return to the decision and requirement it challenges. I use the word verified deliberately. A model-generated explanation of why something happened is a hypothesis. Learning should be grounded in evidence the team can inspect: a reproduced failure, a user-observed pattern, an evaluation result, a persisted system state, or another authoritative receipt. The product record can then show what changed because of that evidence. This keeps the memory curated. Helios is not meant to pour every conversation into an ever-growing context window. It should preserve durable decisions, relevant evidence, current constraints, and the causal links needed to make the next product choice. Superseded context can remain auditable without continuing to govern current work. ## What this changes for GenAI product management Treating context as architecture changes the PM job from producing handoff documents to designing a decision system. I have to define which evidence is eligible, who owns it, how it becomes a requirement, what authority an agent or team has, how completion will be verified, and which result should update the roadmap. It also creates a better interface between specialists. Research can see how evidence affected a decision. Engineering can see the product intent and failure contract. Risk and legal can see the authority and review points. Design can make provenance, uncertainty, and escalation usable. Operations can see what must be monitored. The shared artifact is not a giant brief; it is a connected, inspectable chain of judgment. That is the product thesis behind Helios. GenAI can accelerate product work, but durable speed comes from preserving the meaning of the work as it moves. Context is the architecture that lets a team move quickly without asking a model—or a person joining late—to invent the missing why. ## Closing signal The Helios loop is simple to state and demanding to operate: research and decisions become requirements; delivery returns evidence; evaluation tests the intended behavior; verified learning updates what the product knows. When that loop is visible, AI-assisted product work can become faster and more accountable at the same time. The system is not trusted because it remembers more. It is trusted because teams can inspect what informed the decision, what changed, and what the evidence says to do next. --- # Agents Should Re-strategize When the Work Changes Source URL: https://viswas.dev/knowledge/chatter-adaptive-agent-coordination Knowledge index: https://viswas.dev/knowledge Essay public Field note · Adaptive agent coordination The coordination problem is not whether agents can exchange updates. It is whether an affected agent can prove that peer work changed its plan, adapt without exceeding its authority, and leave evidence of what it revised and why. - Author: Viswas Vuppala - Type: Essay - Reading time: 11 min read ## Messages create awareness; they do not reconcile plans When several agents work in parallel, it is tempting to treat communication as the coordination layer. Give each agent a mailbox, publish progress events, and let everyone subscribe. That solves an important transport problem, but the harder product question begins after a relevant update arrives. Imagine one agent completes a shared data contract while another is building a consumer against an earlier assumption. The second agent can read the completion message and continue anyway. It can acknowledge the message without revising its tests, sequence, or definition of done. Every participant can appear informed while the combined plan quietly drifts apart. Useful coordination therefore needs an observable adaptation step. The affected agent should verify the completed work, identify which part of its active plan depends on the change, decide what it may revise within scope, and publish evidence of that revision. I call this dependency-aware reconciliation. > A notification says that something happened. A reconciliation receipt shows what changed because it happened. ## Start with completed peer work, not agent narration Chatter begins with a completed-work event because intent and completion are different states. An agent saying that it plans to change a contract should not cause downstream work to mutate. The coordination layer needs evidence that the relevant artifact or authoritative state actually changed. Verification can be modest and task-specific: inspect the committed artifact, re-read the record, run the relevant check, or confirm the produced interface. The point is not to demand exhaustive proof for every message. It is to keep causal planning decisions anchored to something stronger than another agent's confident summary. This also improves failure handling. If the event cannot be verified, the affected agent can preserve its current plan, request clarification, or escalate. It should not fill the evidence gap with an inferred dependency and then describe the resulting re-plan as coordinated work. ## The Chatter reconciliation loop The product loop I am exploring has four visible transitions. First, a peer completes work and provides a verifiable reference. Second, Chatter matches that change to an affected dependency in another agent's active working contract. Third, the affected agent re-strategizes only inside its existing scope and authority. Fourth, it publishes the revised working contract and a reconciliation receipt. The working contract is the plan state that matters for coordination: objective, assumptions, dependencies, owned tasks, constraints, acceptance evidence, and authority boundaries. A revision may change sequencing, replace an invalid assumption, add a verification step, or mark work as no longer necessary. It should not silently expand the agent's mandate. The receipt makes the adaptation causal. It connects the verified peer artifact to the affected dependency, records the before-and-after plan state, identifies the rule or judgment used, and names anything that remains unresolved. That gives people and other agents a basis for review without requiring them to reconstruct the story from a chat transcript. - Verify the completed peer artifact or authoritative state. - Match the change to an explicit dependency, assumption, task, or acceptance condition. - Revise strategy within the agent's existing objective, tools, permissions, and change scope. - Publish the revised working contract plus a causal reconciliation receipt. ## What Chatter is—and is not A mailbox transports messages. That is useful, but delivery and acknowledgement do not prove that a dependent plan changed. Chatter is interested in the state transition after receipt: whether the message corresponds to verified work, what it affects, and what adaptation follows. Model Context Protocol, or MCP, is an open standard for connecting AI applications to external data sources, tools, and workflows. That connectivity can give an agent the evidence and capabilities it needs. It does not by itself decide how a completed peer task should alter another agent's working contract. Agent2Agent, or A2A, addresses interoperability between agents. Google's overview describes capability discovery, task lifecycle, messages, artifacts, and state updates across agents built with different frameworks. Those are valuable coordination primitives. Chatter's narrower hypothesis sits above transport and interoperability: dependency-aware adaptation should be explicit, authority-bounded, and receipted. Centralized orchestration solves a different problem by assigning and sequencing work from a controlling plan. That can be the right architecture. Chatter explores what happens when work is already distributed and the affected agent has local context the coordinator may not possess. The agent can propose a scoped revision, while policy or a person still controls whether higher-impact changes are accepted. - MCP documentation: https://docs.anthropic.com/en/docs/agents-and-tools/mcp - Google's A2A overview: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ ## Adaptation must not become authority expansion An agent that can change its plan is more useful, but it can also turn a small dependency update into an unapproved change in objective, architecture, cost, or external state. The product must distinguish strategy flexibility from authority flexibility. I treat the original working contract as an envelope. Inside it, an agent may reorder owned tasks, refresh an assumption, update a local interface, or add tests required by the verified dependency. Outside it, the agent must propose rather than act. New access, spend, environments, external messages, destructive operations, changed acceptance criteria, or impact on another owner's scope require the appropriate approval path. This boundary belongs in the receipt. A useful receipt says not only what changed, but why the change was permitted. When the adaptation crosses a threshold, the receipt becomes a review packet: evidence, proposed revision, expected effect, and the decision that remains with a human or authorized coordinator. ## Evaluate coherence, not message volume A noisy coordination system can look active while making the team less effective. Message count, agent responsiveness, and task throughput are operational measures; they do not tell me whether parallel plans remained coherent. I would evaluate Chatter against dependency scenarios with known expected effects. Did it identify the correct affected plan? Did it avoid changing unrelated work? Was the peer completion actually verified? Did the revision remain within authority? Could a reviewer trace the before-and-after state to its cause? Did the combined work integrate with less rework or fewer contradictory assumptions? False positives matter as much as misses. If every completion triggers re-planning, agents will churn and destroy stable work. The product needs thresholds for relevance, materiality, and confidence, plus a clean no-change receipt when a verified event does not justify adaptation. - Dependency-match precision and recall - Verified-evidence coverage before adaptation - Scope and authority adherence - Causal trace completeness - Unnecessary re-plan rate - Integration rework and unresolved-conflict rate ## The product manager designs the reconciliation policy This is not only an infrastructure problem. Product managers have to define which changes are material, which plan elements are safe to revise automatically, what evidence is authoritative, when a person should decide, and what the receipt must make understandable. The work resembles designing a customer journey across agents. There is an initiating event, an affected participant, a decision point, a state transition, an exception path, and an observable outcome. The fact that the participants are software agents does not remove the need for clear value, constraints, usability, and trust. A good policy will be domain-specific. A documentation agent may safely update references after a verified interface change. An agent handling production access, financial commitments, regulated decisions, or customer communication should have a much narrower automatic envelope. Coordination quality comes from making those distinctions explicit. ## What Chatter proves today—and what it does not Chatter is a local prototype. A real local SQLite-backed service and dependency-matching workflow have been exercised through simulated agent sessions. That is useful evidence for the data model and reconciliation concept, but it is not proof of a production-ready multi-agent system. Most importantly, the end-to-end live Codex-to-Claude workflow remains unproven. I do not describe the prototype as live multi-provider coordination, and I do not treat a simulated demo as evidence that independent agents will reliably verify, re-strategize, and reconcile under real operating conditions. The next proof should be narrow: one real dependency, one completed peer artifact, one affected working contract, one bounded adaptation, and one receipt that a reviewer can independently verify. The value of Chatter will not come from adding another channel for agents to talk. It will come from demonstrating that distributed work can adapt coherently without hiding cause or expanding authority. ## Closing signal Agent ecosystems need protocols, tools, and messages. They also need a product model for what happens when new work invalidates an active plan. My standard is straightforward: verify the change, identify the dependency, re-strategize within scope, and leave a receipt. If the system cannot show that loop, the agents may be communicating—but they are not yet coordinating in a way I would trust. --- # Your Next Customer Might Be an AI Agent Source URL: https://viswas.dev/knowledge/agents-are-customers Knowledge index: https://viswas.dev/knowledge Essay public Field note · Agent experience Products are still designed for people, but an agent may increasingly be the participant that finds the information, interprets the interface, calls the tool, and completes the task on a person's behalf. That makes agent experience a product-management responsibility. - Author: Viswas Vuppala - Type: Essay - Reading time: 11 min read ## A new participant has entered the customer journey Product teams are accustomed to designing for a person at a screen. The person discovers the product, learns the language, navigates the interface, enters information, recovers from errors, and decides whether the outcome is trustworthy. AI agents are beginning to perform some of those steps between the product and the person they serve. I do not mean that every agent is an economic buyer or that human-centered design is becoming optional. I mean that an agent can be a distinct user or intermediary with its own success conditions. If it cannot find the authoritative page, distinguish current content from stale content, understand an action, recover from an error, or verify the result, the human's task still fails. That makes the agent a customer persona worth designing for. The useful PM question is not ‘How do we optimize everything for bots?’ It is ‘Where does an agent participate in this journey, what is it trying to accomplish for the user, and what product qualities determine whether it succeeds?’ > The agent is not the reason the product exists. It may be the customer participant that determines whether the human gets the outcome. ## Define the agent persona by task and authority A useful persona is more specific than ‘AI agent.’ A research agent gathering public facts has different needs from an enterprise assistant using approved internal sources, a procurement agent preparing a transaction, or a coding agent changing a repository. Their information access, tools, error costs, and approval boundaries differ. I define the persona around five questions: Who is the human principal? What task is the agent trying to complete? Which information and actions are in scope? Which decisions remain with a person? What evidence will prove that the outcome is correct? Those answers turn an abstract trend into product requirements. They also prevent a common mistake: optimizing only for model ingestion. A page that is easy to summarize but leads an agent to an unauthorized or unverifiable action is not agent-ready. The experience must support the whole journey from discovery through trustworthy completion. ## 1. Findability: can the agent locate the right thing? Agents need stable, crawlable, addressable product information. Descriptive URLs, consistent canonical paths, accurate page titles, metadata, and machine-readable indexes reduce the chance that the agent starts from an obsolete or ambiguous surface. Public information should be discoverable; private information should remain deliberately inaccessible rather than accidentally exposed for optimization. Structured data can provide explicit clues about what a page represents. Google's guidance describes structured data as standardized in-page markup that helps classify content and says the markup should describe the content visible on that page. I apply the same truth constraint to agent-facing resources: machine-readable representations should synchronize with the human-facing source instead of creating a richer, contradictory shadow site. Findability is not a promise that every agent or search system will use every file or schema. It is a product decision to provide durable entry points and consistent meaning, then test which clients can actually locate the correct source. - Stable canonical URLs and redirects when paths change - Descriptive titles, headings, metadata, and content dates where freshness matters - Structured data that matches visible page content - Machine-readable indexes for public material, with private and noindex boundaries preserved - Google structured-data guidance: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data ## 2. Understandability: can the agent form the right model? Once an agent reaches a page, it needs a coherent information hierarchy. Semantic HTML, one descriptive primary heading, meaningful section headings, real links and buttons, explicit labels, useful image alternatives, and predictable navigation provide structure that is more reliable than visual position alone. This is where accessibility and agent experience overlap—but they are not the same requirement. Accessible design is for people, including people who use assistive technologies, and should be pursued because equal access is a human obligation. W3C guidance explains how browsers and assistive technologies derive accessible names and recommends visible text and native techniques where possible. Those semantic names can also give machine clients more useful signals, but accessibility standards should never be reframed as a bot-optimization checklist. The PM requirement is to preserve meaning across presentations. A card should not depend on color alone to communicate status. A control should not be called ‘click here.’ A diagram should have a textual explanation. If the product exposes the same concept through a page, API, and machine index, the names and state model should agree. - W3C guidance on accessible names and descriptions: https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/ - Prefer semantic HTML and visible, descriptive labels before adding custom ARIA. - Treat accessibility as a human requirement; describe machine-navigation benefits as a secondary consequence of clear semantics. ## 3. Usability: can the agent complete the task? Readable content may be enough for a research task. Transactional work often needs a documented API or tool interface with explicit inputs, outputs, schemas, permissions, and error states. The right interface depends on the job; not every product needs a new protocol or a collection of autonomous actions. MCP is one useful option. Anthropic's documentation describes it as an open standard for connecting AI applications to external data sources, tools, and workflows. A2A addresses another layer: Google's overview describes cross-agent capability discovery, task lifecycle, messages, artifacts, and state updates. These protocols can improve connectivity and interoperability, but neither substitutes for a well-designed product contract. I start with the smallest interface that makes the user task reliable. That may be semantic content, a structured feed, an existing API, an MCP server, an A2A-capable service, or a human-confirmed workflow. The product should not force a protocol into the architecture simply because agents are involved. - MCP documentation: https://docs.anthropic.com/en/docs/agents-and-tools/mcp - Google's A2A overview: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ - Document inputs, outputs, units, state transitions, limits, permissions, and recoverable errors. - Make read, propose, act, and verify distinct capabilities where consequences differ. ## 4. Trust: can the agent act without inventing authority? Agent usability without trust can make a product easier to misuse. I want every consequential interaction to carry a scoped authority model: what the agent may read, what it may propose, what it may change, which identity it represents, and where approval is required. Errors should be useful to both the agent and the person. ‘Something went wrong’ encourages retries without learning. A better error identifies the invalid field, missing permission, stale version, rate limit, conflict, or unavailable dependency and states whether retrying is safe. Idempotency matters because agents may repeat calls after a timeout; a duplicate request should not create a duplicate consequence. Completion also needs receipts. A successful request is not always proof that the intended state exists. The interface should return a stable record identifier, version, persisted state, test result, or another authoritative signal that the agent can re-read. When verification is impossible, the product should represent the outcome as attempted or pending—not completed. - Least-privilege scopes tied to a clear principal - Approval for material, external, destructive, regulated, or costly actions - Specific errors with safe retry guidance - Idempotency keys and conflict handling for repeatable actions - Authoritative receipts and read-after-write verification ## 5. Measurement: did the agent help the user succeed? Agent readiness is not proven by publishing a robots file, schema, or protocol endpoint. I need task-level evidence. Can representative agents find the current source? Can they distinguish the product, project, person, or action correctly? Can they complete the intended task inside policy? Can they recover from expected failures? Can they show the person what happened? Measurement should include the human outcome. An agent can complete a tool call while selecting the wrong account, misreading freshness, or creating more review work than it removes. I would pair machine task completion with correctness, user confirmation, correction patterns, escalation quality, time saved, and the severity of failures. I would also test across clients. Agent behavior changes with models, tools, context limits, and runtime policies. The product contract should be stable enough that different agents can discover and use it, while the evaluation shows where compatibility remains partial. - Correct-source discovery rate - Task completion with policy adherence - Field, state, and action accuracy - Recovery from missing permissions, conflicts, stale data, and timeouts - Verified-outcome coverage - Human correction, override, escalation quality, and end-to-end task success ## A product-management playbook for agent experience I would add agent experience to the normal product-development cycle, not create a separate innovation theater around it. Discovery identifies where agents already participate and where customers want delegation. Journey mapping marks the handoffs between person, agent, interface, and system of record. Requirements define information, tools, authority, failures, and receipts. Evaluation tests the task across representative clients. Prioritization should follow user value and risk. A public knowledge site may begin with stable pages, semantic structure, accurate metadata, and synchronized machine indexes. A workflow product may prioritize permissioned APIs, idempotent mutations, dry runs, approvals, and verification. A marketplace may need identity, delegation, and dispute states before broad autonomous access. The strategic opportunity is larger than making a site easy to crawl. Products that serve agents well can become easier to integrate, easier to verify, and clearer about their own state. Those improvements also help human teams because they force the product to make its meaning, contracts, and boundaries explicit. ## Closing signal The next customer journey may move through a person, an agent, several tools, and another agent before returning an outcome. Product managers need to own that journey with the same discipline we apply to any other experience. Design for findability, understandability, usability, trust, and measurable completion. Keep accessibility grounded in human access. Use protocols where they solve a real interface problem. Above all, remember that the agent's success is only valuable when it produces a correct, legible outcome for the person it represents. --- # Physical AI Is a Hardware-Software Product Source URL: https://viswas.dev/knowledge/physical-ai-hardware-software-codesign Knowledge index: https://viswas.dev/knowledge Essay public Field note · Physical AI product design A model can interpret a request, but it cannot compensate for an unstable chassis, an exposed mechanism, an ambiguous handoff zone, or a missing hard stop. Physical AI works only when the intelligence and the object are designed as one product. - Author: Viswas Vuppala - Type: Essay - Reading time: 11 min read ## The product is the behavior of the whole system Software lets teams change behavior quickly. Hardware makes every assumption tangible. Weight distribution changes braking. Lighting changes perception. A loose cable becomes a reliability problem. A delayed response becomes physical motion that continues after the user expected it to stop. That is why I treat physical AI as hardware-software co-design, not an AI feature placed inside a device. Zyner + Treaty is my pre-build concept for exploring that discipline through a playful use case: a compact, local-first Raspberry Pi rover that can bring Kova a treat at a predefined floor pad or carry a small personal item to an adult-authorized handoff point. The two functions use separate enclosed interfaces, and nothing is thrown, launched, or aimed. The rover has not been constructed or safety-validated. The concept is valuable because it forces product decisions across perception, language, mechanics, motion, dispensing, permissions, and testing before the experience can be called real. > In physical AI, a plausible response is not an outcome. The outcome is what the entire machine did in the real environment—and whether it stopped safely when an assumption failed. ## Translate the playful promise into system boundaries The product promise sounds simple: ask for a treat delivery or a personal handoff and watch the rover complete it. That sentence hides several decisions. Who may request each mode? Where may the rover travel? How does it know it reached the correct zone? When may a bay open or a cassette dispense? What happens when the path, camera, sensor, network, or language interpretation is uncertain? I separate the experience into two physical modules. Treaty is a guarded treat cassette that can dispense only while the rover is stationary in a verified treat zone. Zyner is an enclosed bay for a small personal item that remains closed until the rover is stopped at an approved adult handoff zone. A request for one module cannot authorize the other. This separation is product architecture. It reduces ambiguous states, gives each workflow its own authorization and test plan, and lets the physical design prevent software confusion from becoming unintended actuation. - One low-speed rover, two independently authorized payload workflows - Fixed, familiar delivery zones rather than unconstrained roaming - Enclosed handoff bay and guarded treat cassette - No launcher, targeting behavior, or release while moving - Accessible emergency stop and a default-to-stopped failure state ## Give AI perception and language—not the final safety decision AI can make the interaction more natural. It can help interpret a spoken request, recognize a known zone or visual marker, identify an obstruction, and explain what the rover believes is happening. Those capabilities are probabilistic. Their uncertainty should inform the experience, but they should not be the only gate between a request and physical motion. I place deterministic control beneath the AI layer. A finite-state controller governs states such as idle, authorized, navigating, stopped-at-zone, ready-to-handoff, dispensing, completed, and faulted. Sensors, zone checks, interlocks, timeouts, speed limits, and a hard stop determine which transitions are physically allowed. The model can propose an intent; the controller decides whether the current state satisfies the rule. Google DeepMind describes a layered robotics-safety approach in which vision-language-action models are composed with lower-level safety mechanisms, alongside semantic-safety evaluation and vulnerability assessment. The implementation details differ from a hobby rover, but the product principle transfers: model reasoning should complement, not replace, controls that constrain the machine's motion and effects. - Google DeepMind on responsible robotics safety: https://deepmind.google/models/gemini-robotics/responsibly-advancing-ai-and-robotics/ ## Mechanics, power, and interaction design are product requirements A software requirement like ‘stop when blocked’ is incomplete until the team knows sensor coverage, stopping distance, wheel slip, floor transitions, payload mass, motor behavior, and what happens when power drops. The physical form determines whether the control policy can keep its promise. For Zyner + Treaty, I would prioritize a low, stable deck; protected wheels and camera; tidy strain-relieved wiring; guarded moving parts; independent physical interlocks; and access to the emergency stop without reaching into a mechanism. Battery state should constrain which task can begin, and loss of perception, control communication, or a required sensor should transition to stopped rather than improvise. Interaction design is equally physical. Status needs to be legible from across a room through restrained light and sound cues. The person should know whether the rover heard a request, is waiting for authorization, is moving, reached a zone, cannot proceed, or is safe to approach. Kova should not need to interpret a screen, and the system should not rely on the dog's behavior to establish a safety state. ## Local-first is an experience and reliability choice A local-first Raspberry Pi architecture can reduce unnecessary data movement, preserve core behavior when internet access is unavailable, and keep the control loop close to the sensors and motors. It does not make the system safe by itself. Local models can still be wrong, and a local computer can still crash. Official Raspberry Pi documentation shows that Raspberry Pi 5 can run vision AI workloads with supported cameras and AI accelerators, and that different models carry speed and accuracy tradeoffs. That makes local perception technically plausible. It does not prove that a particular model, camera placement, lighting condition, latency, thermal profile, or power budget will satisfy this rover's product requirements. I would therefore select compute after defining the task envelope and measurement plan. Perception latency, frame rate, model quality, power draw, startup time, thermal behavior, and graceful degradation all belong in the product tradeoff—not just whether a demo can detect an object. - Official Raspberry Pi AI documentation: https://www.raspberrypi.com/documentation/computers/ai.html ## Measure the AI, robot, and task together Robotics evaluation cannot stop at model accuracy. NIST's Physical AI work emphasizes the relationship among the AI algorithm, robot system, and task, and the need for metrics and test methods that characterize real-world feasibility, safety, cost, and productive output. That framing is useful well beyond manufacturing. For this concept, perception quality matters only in relation to the rover's behavior. A missed zone marker has a different product consequence if the finite-state controller keeps the bay locked and stops than if it allows a release. Navigation time matters alongside stopping accuracy, intervention rate, payload stability, battery reserve, and recovery from sensor faults. The evaluation unit should therefore be a scenario: a defined starting state, environment, request, payload condition, expected state transitions, allowed timing, safety constraints, and authoritative evidence of the outcome. That turns ‘the model worked’ into a product claim that can be tested. - NIST Physical AI and Data Generation for Robotics: https://www.nist.gov/programs-projects/physical-ai-and-data-generation-robotics - Zone-recognition and stopping accuracy under representative lighting and floor conditions - Obstacle response, minimum stopping behavior, and false-clear rate - State-transition, authorization, and interlock correctness - Handoff and dispensing success while stationary - Fault recovery, emergency-stop response, and safe power-loss behavior ## Validation should earn physical capability in stages A staged plan protects against the excitement of a working subsystem being mistaken for a working product. I would begin with component fit, wiring, power, logging, and the emergency stop. Then I would validate the finite-state controller with motors disconnected, followed by an empty base at low speed inside a fixed test zone. Only after repeatable stop, obstruction, zone, timeout, and power-loss tests would I add an empty enclosure. Payload mass comes later. Dispensing begins with inert test objects and no dog or person in the zone. Adult handoff tests begin with the rover immobilized, then progress through controlled low-speed trials. Every stage needs explicit pass criteria and a stop condition for redesign. This sequence is deliberately conservative because a safe demo is not the same as a safe product. Variability in floors, lighting, battery state, pets, people, and household clutter will expose interactions that isolated component tests cannot. A concept can describe the intended layers; only measured trials can validate them. - Bench test: power, sensors, logs, interlocks, and emergency stop - Controller test: simulated state transitions with actuation disabled - Empty-base test: fixed zone, low speed, no payload, no people or pets - Empty-module test: locked enclosures and fault injection - Inert-payload test: stationary release at verified zones - Controlled supervised trials only after every earlier gate passes ## The PM job is to keep the layers honest Hardware-software co-design gives product managers a concrete version of work that also matters in enterprise GenAI: translate an experience into system boundaries, separate probabilistic judgment from deterministic policy, define authority, design failure states, and require evidence before broadening scope. It also requires cross-functional sequencing. Mechanical design constrains sensor placement. Power constrains compute. Model latency constrains motion. Industrial and interaction design determine whether the user understands the state. Safety requirements reshape all of them. A roadmap that treats those as independent tracks will discover the integration risk late. Zyner + Treaty is intentionally a pre-build experiment, not a claim of finished hardware. Its current value is the product architecture and the questions it makes unavoidable. If the idea advances, each new capability should be earned by a measured system outcome—not by a rendering, a parts list, or a successful model demo. ## Closing signal Physical AI is compelling because intelligence can leave the screen and become useful in the world. That same transition raises the standard of evidence. Product behavior now includes mechanics, power, motion, interaction, and the environment—not only the model's response. Design the object and the intelligence together. Keep AI inside a deterministic safety envelope. Validate the model, robot, and task as one system. And do not call the concept complete until the physical evidence earns the claim. --- # Beyond Work Source URL: https://viswas.dev/beyond-work Beyond the work / Beyond Work / Kova / Golf / Poker / AI Ready RVA Energy / Reflection / Community # Kova, golf, poker, and AI Ready RVA. Kova keeps me active. Golf gives me space to think. Poker keeps me honest about incomplete information. AI Ready RVA keeps me connected to product peers who are learning how to put AI to practical use. ## Kova ## Kova, my golden retriever Kova gets me outside, keeps me moving, and makes an ordinary day more fun. > Most days, he is simply very good company. ## Golf ## Golf Golf gives me a few quiet hours outside with friends and room to think. > I like the walks, the good shots, the terrible ones, and the conversations in between. ## Poker ## Poker Poker is one of my favorite ways to spend an evening with friends. > I enjoy reading the table, living with uncertainty, and laughing when the cards have other plans. ## AI Ready RVA ## AI Ready RVA I volunteer with AI Ready RVA’s Product & AI Cohort, helping product managers apply AI tools and practical best practices across the product development cycle. [Visit the Product & AI Cohort](https://www.aireadyrva.com/cohorts/product-ai) > I value the chance to help other product managers build confidence with AI in their day-to-day work. Back to the work - [Software](https://viswas.dev/software) - [Career](https://viswas.dev/career)