# Agents — MESHHETU Source: https://meshhetu.com/agents Last updated: 2026-10-16 Agents # Explore the specialist agents behind the methodology. These six roles illustrate the developing ROQIVA architecture and the AI-assisted methods behind MESHHETU’s work. Each has a defined input, output and review boundary; this is not a catalog of independently available agents. Agents One artifact each Analyst Research Architect Product Design QA Brain Analyst writes · Finding card Find gaps between signals and decisions. Write evidence-labelled finding cards. Then · Founder review, then Gate 1 Research writes · Notes and a dated brief Bring outside evidence for one decision. Then · Requester accepts Architect writes · Reuse note, system design, impact report Design the target system in plain terms. Then · Gate 2, then engineer review Product writes · Solutions, requirements, PRD revisions, patches Own problem framing, solutions, requirements and the PRD. Then · Gate 2, then Gate 3 Design writes · Prototype HTML, requirement-to-screen map Turn requirements into a reviewable prototype. Then · Gate 3 QA writes · Checklist, QA report Define and report the checks that prove the change works. Then · Gate 3 for the checklist, Gate 4 for the report On this page - Analyst - Research - Architect - Product - Design - QA - Code - Handoffs - Rules - Evidence - By track Agent 01 · Analyst ## Find gaps between signals and decisions Turn detector hits and questions into finding cards a PM can decide on. Modes Triage Card Asked question Regression Starts when Detectors raise a gap, an audit cycle runs, or a person asks why a number moved. Reads Systems, Journeys, Data and Logic sections. Signal aggregates. Writes Finding card Goes to Founder review, then Gate 1 ### Hands over Finding card, to founder review (v1), then Gate 1. ### Never Approves its own finding, reports an unseen area as healthy, or computes counts. Code computes. How it works, step by step - 01 Reads the flagged gap and the Brain slice: the brand’s tools, data model, rules and metrics. - 02 Writes the intended behaviour: what the brand’s own rule, campaign or flow is meant to do with this signal. A payment failure reason should decide how the failure is retried. - 03 Writes the observed behaviour: what the data shows actually happens. The retry rule treats every failure the same. - 04 Checks the evidence: finds the source for each claim and has code reproduce the counts. The gap between intended and observed is the finding. - 05 Labels it Confirmed, Supported or Hypothesis. Dormant data stays Hypothesis until its owner confirms. - 06 Sizes value as a range, sets effort and owner, and lists what it could not see. - 07 Ranks it in the incident or the opportunity lane. Under the hood Tools - brain_read - signals_query - artifact_write Skills - diagnosing-signal-gaps - writing-finding-cards - citing-evidence - reading-brand-context - handing-off-artifacts Run pattern One loop and a clean-context verifier. Every agent also preloads three shared skills: citing evidence, reading brand context and handing off artifacts. WI-014 Analyst Findings inbox Analyst Audits the exports Your PM Rank the gaps the Detectors flagged. Analyst - Check Evidence for each gap - Rank Value × confidence ÷ effort Ranked the findings. F-001 comes first. Evidence is labelled, and nothing here is a measured result. Your PM Approve F-001. Open the work item. Ask the Analyst Analyst Findings inbox Ranking 6 ranked - F-001 Failed payments get one retry Payments → CRM retry rule Incident Supported 9 - F-002 Zero-result searches never reviewed Search log → range planning Opportunity Supported 3 - F-004 Courier delay events unused Orders → customer messages Incident Confirmed 3 - F-003 Notify-me sign-ups never read Storefront → restock messages Opportunity Hypothesis 2 - F-006 City stock shown as one national total Inventory → product page Incident Supported 1.5 - F-005 COD rule with no refusal history Orders → COD eligibility Opportunity Supported 1 Score = value × confidence ÷ effort. Sample values, not measurements. Gate 1 Brand PM confirms the problem is real and worth fixing. Approve Waiting Approved Agent 02 · Research ## Bring outside evidence for one decision Bring outside evidence on how others solve the problem. Modes Internal recall External scan Benchmark brief Refresh Starts when Gate 1 is approved, or a designer, PM or growth lead asks for a standalone benchmark. Reads A confirmed finding. Internal recall reads Journeys, Logic, accepted learnings and problem memories. External scan reads the web. Writes Notes and a dated brief Goes to Requester accepts ### Hands over Dated brief, to Product (and to Design when a designer asked). ### Never Presents a benchmark as a measured result for this brand. It works from outside sources only and sees no customer data or credentials. How it works, step by step - 01 Reads the confirmed finding and the decision it affects. - 02 Gathers how comparable brands and vendors solve it, with source and date on every claim. - 03 Keeps conflicting evidence visible. - 04 Writes a dated brief. ### Two modes, so private data and the open web never meet in one run Internal recall reads the Brain and has no network tools. External scan searches the web and sees only a sanitised question. A brief combines both, with every claim labelled, dated and sourced. Under the hood Tools - web_search - web_fetch - artifact_write Skills - researching-decision-briefs - weighing-sources - citing-evidence - reading-brand-context - handing-off-artifacts Run pattern Gather loop, then one writing call. Every agent also preloads three shared skills: citing evidence, reading brand context and handing off artifacts. WI-014 Research agent Dated brief Research agent Brings outside evidence Your PM How do others handle failed-payment retries? Label what is internal and what is external. Research agent - Recall Internal decision register - Scan Outside sources Research agent Brief drafted. Every claim is labelled internal or external, dated and sourced. It goes to Product with the evidence label. Ask the Research agent Research agent Dated brief · how others solve it Researching Brief drafted - Internal recall Sourced Dated - External scan Sourced Dated - Internal recall Sourced Dated Every claim is labelled internal or external, dated and sourced. Conflicting evidence stays visible. This is a layout, not a brief. Agent 03 · Architect ## Design how the fix fits the existing system Design how the fix fits your existing tools, rules and data. Engineers then specify the APIs and code. Modes Reuse and clash System design Preflight Revise Starts when Gate 1 is approved (reuse and clash check), Gate 2 is approved (system design), or an engineer or PM asks “will this break anything?” or “configure, integrate or build?” Reads Finding, Systems, Data and Logic, Delivery sections. The dependency graph. Writes Reuse note, system design, impact report Goes to Gate 2, then engineer review ### Hands over Reuse note and clash list, to Product. System design and build brief, to Product, QA and the engineers who detail it. ### Never Writes API contracts, payloads, schemas or code. How it works, step by step - 01 Reads the finding and the Systems, Data and Logic sections. - 02 Finds what already exists and can be reused. - 03 Checks the dependency graph for rules, campaigns and tracking the change could clash with. - 04 After Gate 2, draws the target system design: which tools change, and what each must capture, read or pass on, in plain terms. - 05 Lists what must exist first and what the change touches. - 06 For configure, integrate or build, compares the paths at system level: fit, cost and what each replaces. Under the hood Tools - brain_read - graph_query - artifact_write Skills - mapping-system-dependencies - designing-target-systems - drawing-system-diagrams - citing-evidence - reading-brand-context - handing-off-artifacts Run pattern One loop. Every agent also preloads three shared skills: citing evidence, reading brand context and handing off artifacts. WI-014 Architect agent System design Architect agent Checks reuse and clashes Your PM What changes, and what could clash? Architect agent - Read CRM retry-rule configuration - Map Systems that change - Check Journeys that message on failed orders Architect agent Mapped 3 changes. One clash found, and it is flagged for the pack before Gate 3. Ask the Architect agent Architect agent System design · what changes Mapping 3 changes Payments Change Capture the failure class CRM Change Branch the retry rule Analytics New Add retry events Win-back journey Clash Also messages on failed orders. Clash check: the win-back journey also messages on failed orders. Agent 04 · Product ## Own the problem framing, the solutions and the PRD Own the problem framing, the product solutions and the PRD. Modes Solutions Requirements PRD revision Patch Tracking check Starts when Gate 1 is approved (solutions), Gate 2 is approved (requirements and PRD draft), the prototype or system design changes (PRD revision), or the PM edits the PRD or asks a question. Reads Finding, brief, reuse note, design, prototype summary. Writes Solutions, requirements, PRD revisions, patches Goes to Gate 2, then Gate 3 ### Hands over Solutions, to Gate 2. Requirements, to Design. PRD and tracking gap list, to Gate 3. ### Never Overwrites text a person saved. How it works, step by step - 01 Frames the problem from the finding, the brief and the reuse note. - 02 Drafts two or three product solutions, including the cheapest one (configure, buy, build or run manually), with trade-offs, evidence and an agent pick. - 03 After Gate 2, writes the requirements, the user flow and every state (default, error, pending, success) as the brief for Design, and starts the PRD draft from the fixed template. - 04 Keeps the PRD current as the prototype and system design change, including what must be tracked. A missing fact becomes an open question, never a guess. - 05 Returns every PRD change as a reviewable patch against the revision the PM saw. - 06 Answers “does this event already exist?” against the tracking register. ### Product metrics are proposed, never invented Product proposes a north star, input metrics and guardrails, each tied to a definition and the data that would verify it. The PM confirms. A metric the data can’t compute becomes an open question. Under the hood Tools - brain_read - artifact_write - patch_propose - ask_human Skills - proposing-product-solutions - writing-requirements - coauthoring-prds - proposing-prd-patches - citing-evidence - reading-brand-context - handing-off-artifacts Run pattern One loop. The sole writer of the PRD. Every agent also preloads three shared skills: citing evidence, reading brand context and handing off artifacts. WI-014 Product agent PRD.md Product agent Drafts from the Brain Your PM Turn the Gate 2 decision into a spec our engineers can build. Product agent - Read Finding F-001 - Read Gate 2 decision - Read Order events - Write PRD.md Product agent Wrote PRD v1: four requirements, three events and three acceptance checks. It is a draft until Gate 3. Finding F-001 Gate 2 decision Your PM R2 Why never retry a hard decline? Product agent - Read Payments export - Read CRM retry rule A hard decline is a final refusal from the bank, so a retry rarely changes the result and can look like a second charge attempt. This rests on the failure codes in the export, not on a measured retry result. Supported Payments export CRM retry rule Unseen Card-network decline reasons were not in the export. Your PM Comment on R3 Bank-side failures have no error state. Add one. Product agent - Read Comment on R3 - Edit R3 and the Error state Added bank-side failures to R3 and to the Error state in the wireframe. Linked to the Gate 2 decision. Ask the Product agent Product agent PRD.md Empty Writing Draft v1 Revising Draft v2 ### Retry failed payments by failure type Owner · Your PM WI-014 Gate 3 #### 01Problem The CRM retry rule treats hard, transient and bank-side failures the same. Gateway failure codes are captured and never read. #### 02Goal Retry each failure type the way it should be retried, and leave unrecoverable failures alone. #### 03Requirements - R1 Capture the failure class on every failed payment attempt. - R2 Retry transient failures once, after a short delay. Never retry a hard decline. - R3 Show an error state with a next action for hard and transient failures. Show an error state with a next action for hard, transient and bank-side failures. Changed Your PM Comment Resolved Bank-side failures have no error state. Add one. Comment - R4 Send retry_attempted and retry_result with the failure class. #### 04Metrics North star Orders recovered from failed payments Input Retry success by failure type Guardrail Duplicate charges, complaint rate #### 05Tracking - retry_attempted A retry starts - retry_result A retry ends - failure_class On the order event #### 06Acceptance - Tracked events fire on retry - The failure path completes - The screen matches the wireframe #### 07Open questions Open Card-network decline reasons were not in the export. Who owns them? Gate 3 PM, designer and engineer review the pack. Not sent Waiting for review Agent 05 · Design ## Turn requirements into a reviewable prototype Turn requirements into a reviewable HTML prototype in the brand’s design system. Modes From Product From a designer Revise Starts when Gate 2 is approved (from Product), a designer asks for a screen, variation or extra state, or the PRD changes or someone comments (revise). Reads Requirements, the Design section, the current prototype. Writes Prototype HTML, requirement-to-screen map Goes to Gate 3 ### Hands over Prototype and requirement-to-screen map, to Product (for the PRD) and Gate 3. ### Never Sees customer personal data, or shows behaviour that does not exist yet without labelling it simulated. How it works, step by step - 01 Resolves brand context from the design system in the Brain. With none on file, it infers one from the live site and labels it inferred. - 02 Drafts screens covering every state and maps each requirement to a screen. - 03 Checks the draft against the design system. - 04 Publishes a new revision in the workspace, interactive and shareable. A synced copy goes to the design tool when one is connected. - 05 On a revision, updates only the affected screens and keeps the old revision. Under the hood Tools - brain_read - artifact_write - html_check Skills - building-html-prototypes - applying-design-systems - designing-states-and-flows - citing-evidence - reading-brand-context - handing-off-artifacts Run pattern Draft, check, revise. Every agent also preloads three shared skills: citing evidence, reading brand context and handing off artifacts. WI-014 Design agent failed-payment.fig Design agent Prototypes from the PRD Your PM Turn the PRD into a prototype. Four states, one flow. Design agent - Read PRD v2 · R1 to R4 - Read Design system tokens - Build 4 frames Design agent Built four frames from the PRD. Every requirement maps to a screen. Simulated behaviour is labelled. Your designer Comment on Error Offer “Keep my cart” as a second action. Design agent - Read Comment on Error - Edit Error · add link Added “Keep my cart” under the main action in the Error frame, with the Link / Secondary component. Ask the Design agent Design agent failed-payment.fig Empty Building Editing 4 frames - Layers - Frame 01 · Default - Frame 02 · Error - Frame 03 · Pending - Frame 04 · Success 01 Default R1 Review order Pay ₹ —— Pay now 02 Error R3 Payment didn’t go through Your bank declined it. Try another method. Try another method Keep my cart Your designer Comment Resolved Offer “Keep my cart” as a second action. Comment 03 Pending R2 Retrying… We’ll confirm in a moment. 04 Success R4 Order placed We’ve sent the details. View order ⌘ D Gate 3 PM, designer and engineer review the pack. Not sent Waiting for review Agent 06 · QA ## Define and report the checks that prove the change works Define and report the checks that decide whether a release is safe. Modes Plan Report Browser checks Starts when A prototype and PRD are in draft (checklist), a candidate is on staging (run), or a fix arrives (re-check). Reads PRD, prototype summary, test results. Writes Checklist, QA report Goes to Gate 3 for the checklist, Gate 4 for the report ### Hands over Checklist, to Gate 3. QA report, to the Gate 4 approver. ### Never Certifies an environment it did not test. A failure blocks release. How it works, step by step - 01 Maps every acceptance criterion to a check and proposes edge cases. - 02 Runs what staging supports: tracked events fire, the flow completes including failure paths, the screen matches the wireframe. - 03 Hands the rest to people: customer fit, tone of copy, live payment or courier behaviour without test access. - 04 Reports passed, failed and not tested. A re-check runs only the affected checks. Under the hood Tools - brain_read - artifact_write - run_check Skills - deriving-test-checklists - reporting-qa-results - citing-evidence - reading-brand-context - handing-off-artifacts Run pattern One loop. Code runs the checks. Every agent also preloads three shared skills: citing evidence, reading brand context and handing off artifacts. WI-014 QA agent RC-1 QA agent Checks the build Your PM Run the checks on RC-1. QA agent - Run Checks from the pack - Write QA report QA agent One check failed, and a failure blocks release. Two were not tested, and they are not reported as passed. Brand engineer Fixed the error screen. Please re-check it. QA agent - Re-run Screen matches the wireframe Passed. The two untested checks still need a person or test access. Ask the QA agent QA agent QA report · RC-1 Running Blocked Checked 2 passed · 1 failed · 2 not tested 3 passed · 0 failed · 2 not tested Release blocked Ready to sign - Tracked events fire on retry Passed - Failure path completes Passed - Screen matches the wireframe Failed Passed - Live gateway behaviour No test access Not tested - Tone of the error copy Needs a person Not tested Rollback rule agreed before release: pause the branch if duplicate charges appear. A failure blocks release. Not tested is never reported as passed. Gate 4 Brand approver signs one exact release candidate. Sign RC-1 Waiting Signed Code ## Rely on the code around the agents. Anything that computes, routes or measures is code you can reproduce. - payments.failure_code Gap - orders.status Read - search.zero_result_term Gap ### Detectors Match every captured signal to the decision that reads it and flag the gaps. Code, not an agent. Code - 1 - 2 - 3 - 4 ### Orchestrator Opens work items, runs agents in parallel, stops at gates, and is the only writer to the Brain. Code Keep Tune Roll back ### Monitor Checks releases against their spec, catches unplanned changes and measures results against a baseline. It never deploys. Code Handoffs ## Follow the handoff from agent to agent. Read top to bottom. Agents on the same row run in parallel. Agents and handoffs Agent Starts when Reads Produces Hands to Analyst A detector raises a gap, or a person asks why a number moved Detector hits; Systems, Journeys, Data and Logic sections Finding card Founder review (v1), then Gate 1 Research Gate 1 approved, or a person asks for a benchmark Confirmed finding Dated brief: sourced benchmarks, conflicts kept visible Product Architect Gate 1 approved, then Gate 2 approved Finding; Systems, Data and Logic sections; chosen option Reuse note and clash list. After Gate 2: system design (what changes, what depends on it) Product, QA Product Gate 1 approved Finding, brief, reuse note Two or three product solutions with trade-offs and an agent pick (Gate 2). Requirements and every state. PRD draft, kept current as design evolves Design, then Gate 3 Design Gate 2 approved Requirements; Design section Prototype and requirement-to-screen map Product, then Gate 3 QA Prototype and PRD in draft Acceptance criteria, design states, tracking requirements Test checklist (Build step). QA report: passed, failed, not tested (Release step) Gate 3, then Gate 4 Gate 3 releases the handoff pack: PRD, wireframe, tickets, test checklist and sources. For the MVP, the Analyst runs as an agent. Research and Product run as the founders’ internal tools. Design and QA belong to the brand’s team in Tracks A and B. Rules for every agent ## Apply eight rules to every agent. 01 ### Draft only Write to a workspace, a design draft or a branch, never to a live system. 02 ### Evidence on everything Each output cites its source and carries Confirmed, Supported or Hypothesis. A missing fact becomes an open question. 03 ### Versioned and linked Each output links to its finding. A new direction supersedes older artifacts explicitly. 04 ### Minimum context Each agent sees only the slice its task needs. 05 ### Source authority A live order record outranks a stale spreadsheet. Conflicts are shown, not silently resolved. 06 ### Feedback stays local A comment or edit changes that task. Only the owner of a Brain section or a skill can turn it into a standing rule. 07 ### A visible profile Every agent shows its purpose, version, skills, tools, caps, kill switch and latest eval result. Its runs appear in the case timeline under its name. 08 ### A run sees only what its requester may see Restricted Brain sections and sources are left out of its slice, and what it writes carries the same restriction. Absence is not evidence of non-use. Without the decision’s configuration or the owner’s word, a signal is “usage unknown”, a coverage gap rather than a finding. Evidence labels ## Label every claim by how proven it is. - F-004 Courier delay events unused confirmed ### Confirmed Code reproduced the counts. - F-001 Failed payments get one retry supported - F-002 Zero-result searches never reviewed supported ### Supported The evidence is consistent, but the counts are not yet reproduced. - F-003 Notify-me sign-ups never read hypothesis ### Hypothesis Not yet confirmed. Dormant data stays a hypothesis until its owner confirms. By track ## Understand how specialist roles relate to each track. Where each agent runs, by track Agent Track A · Consulting Track B · Modular intelligence Track C · ROQIVA (development) Analyst Internal tool, then a retainer A module, sold Included Research Internal tool Not sold Included Architect A founder, by hand Not sold Included Product Internal tool for PRD drafts Not sold Included Design The brand’s designers Not sold Optional, run by the brand QA The brand’s QA Not sold Optional, run by the brand ## Bring us one complex revenue problem. We can scope a consulting or modular intervention now, or show how a complete agent workflow is envisioned for ROQIVA. [Book a working session](https://meshhetu.com/contact#book) [Open the example run](https://meshhetu.com/examples)