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.

AgentsOne artifact each

Brain

Analystwrites · Finding card

Find gaps between signals and decisions. Write evidence-labelled finding cards.

Then · Founder review, then Gate 1

Agent 01 · Analyst

Find gaps between signals and decisions

Turn detector hits and questions into finding cards a PM can decide on.

ModesTriageCardAsked questionRegression

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

01Reads the flagged gap and the Brain slice: the brand’s tools, data model, rules and metrics.
02Writes 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.
03Writes the observed behaviour: what the data shows actually happens. The retry rule treats every failure the same.
04Checks the evidence: finds the source for each claim and has code reproduce the counts. The gap between intended and observed is the finding.
05Labels it Confirmed, Supported or Hypothesis. Dormant data stays Hypothesis until its owner confirms.
06Sizes value as a range, sets effort and owner, and lists what it could not see.
07Ranks 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-014AnalystFindings inbox

Findings inboxRanking6 ranked

F-001Failed payments get one retryPayments → CRM retry ruleIncidentSupported9
F-002Zero-result searches never reviewedSearch log → range planningOpportunitySupported3
F-004Courier delay events unusedOrders → customer messagesIncidentConfirmed3
F-003Notify-me sign-ups never readStorefront → restock messagesOpportunityHypothesis2
F-006City stock shown as one national totalInventory → product pageIncidentSupported1.5
F-005COD rule with no refusal historyOrders → COD eligibilityOpportunitySupported1

Score = value × confidence ÷ effort. Sample values, not measurements.

Gate 1Brand PM confirms the problem is real and worth fixing.ApproveWaitingApproved

Agent 02 · Research

Bring outside evidence for one decision

Bring outside evidence on how others solve the problem.

ModesInternal recallExternal scanBenchmark briefRefresh

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

01Reads the confirmed finding and the decision it affects.
02Gathers how comparable brands and vendors solve it, with source and date on every claim.
03Keeps conflicting evidence visible.
04Writes 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-014Research agentDated brief

Dated brief · how others solve itResearchingBrief drafted

Internal recallSourcedDated
External scanSourcedDated
External scanSourcedDated
Internal recallSourcedDated

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.

ModesReuse and clashSystem designPreflightRevise

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

01Reads the finding and the Systems, Data and Logic sections.
02Finds what already exists and can be reused.
03Checks the dependency graph for rules, campaigns and tracking the change could clash with.
04After Gate 2, draws the target system design: which tools change, and what each must capture, read or pass on, in plain terms.
05Lists what must exist first and what the change touches.
06For 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-014Architect agentSystem design

System design · what changesMapping3 changes

PaymentsChange

Capture the failure class

CRMChange

Branch the retry rule

AnalyticsNew

Add retry events

Win-back journeyClash

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.

ModesSolutionsRequirementsPRD revisionPatchTracking 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

01Frames the problem from the finding, the brief and the reuse note.
02Drafts two or three product solutions, including the cheapest one (configure, buy, build or run manually), with trade-offs, evidence and an agent pick.
03After 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.
04Keeps 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.
05Returns every PRD change as a reviewable patch against the revision the PM saw.
06Answers “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-014Product agentPRD.md

Product agentDrafts from the Brain

Your PM

Turn the Gate 2 decision into a spec our engineers can build.

Product agent

ReadFinding F-001
ReadGate 2 decision
ReadOrder events
WritePRD.md

Product agent

Wrote PRD v1: four requirements, three events and three acceptance checks. It is a draft until Gate 3.

Finding F-001Gate 2 decision

Your PM

Why never retry a hard decline?

Product agent

ReadPayments export
ReadCRM 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.

SupportedPayments exportCRM retry rule

UnseenCard-network decline reasons were not in the export.

Your PM

Comment on R3

Bank-side failures have no error state. Add one.

Product agent

ReadComment on R3
EditR3 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.mdEmptyWritingDraft v1RevisingDraft v2

Retry failed payments by failure type

Owner · Your PMWI-014Gate 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

R1Capture the failure class on every failed payment attempt.
R2Retry transient failures once, after a short delay. Never retry a hard decline.
R3Show 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 PMCommentResolved
Bank-side failures have no error state. Add one.
Comment
R4Send 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_attemptedA retry starts
retry_resultA retry ends
failure_classOn 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 3PM, designer and engineer review the pack.Not sentWaiting for review

Agent 05 · Design

Turn requirements into a reviewable prototype

Turn requirements into a reviewable HTML prototype in the brand’s design system.

ModesFrom ProductFrom a designerRevise

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

01Resolves brand context from the design system in the Brain. With none on file, it infers one from the live site and labels it inferred.
02Drafts screens covering every state and maps each requirement to a screen.
03Checks the draft against the design system.
04Publishes a new revision in the workspace, interactive and shareable. A synced copy goes to the design tool when one is connected.
05On 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-014Design agentfailed-payment.fig

failed-payment.figEmptyBuildingEditing4 frames

Layers
Frame 01 · Default
Frame 02 · Error
Frame 03 · Pending
Frame 04 · Success

01DefaultR1
Review order
Pay ₹ ——
Pay now
02ErrorR3
Payment didn’t go through
Your bank declined it. Try another method.
Try another methodKeep my cart
Your designerCommentResolved
Offer “Keep my cart” as a second action.
Comment
03PendingR2
Retrying…
We’ll confirm in a moment.
04SuccessR4
Order placed
We’ve sent the details.
View order

Gate 3PM, designer and engineer review the pack.Not sentWaiting 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.

ModesPlanReportBrowser 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

01Maps every acceptance criterion to a check and proposes edge cases.
02Runs what staging supports: tracked events fire, the flow completes including failure paths, the screen matches the wireframe.
03Hands the rest to people: customer fit, tone of copy, live payment or courier behaviour without test access.
04Reports 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-014QA agentRC-1

QA report · RC-1RunningBlockedChecked

2 passed · 1 failed · 2 not tested3 passed · 0 failed · 2 not testedRelease blockedReady to sign

Tracked events fire on retryPassed
Failure path completesPassed
Screen matches the wireframeFailedPassed
Live gateway behaviourNo test accessNot tested
Tone of the error copyNeeds a personNot 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 4Brand approver signs one exact release candidate.Sign RC-1WaitingSigned

Code

Rely on the code around the agents.

Anything that computes, routes or measures is code you can reproduce.

- payments.failure_codeGap
- orders.statusRead
- search.zero_result_termGap
Detectors
Match every captured signal to the decision that reads it and flag the gaps. Code, not an agent.
Code
1. 1
2. 2
3. 3
4. 4
Orchestrator
Opens work items, runs agents in parallel, stops at gates, and is the only writer to the Brain.
Code
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-004Courier delay events unusedconfirmed
Confirmed
Code reproduced the counts.
- F-001Failed payments get one retrysupported
- F-002Zero-result searches never reviewedsupported
Supported
The evidence is consistent, but the counts are not yet reproduced.
- F-003Notify-me sign-ups never readhypothesis
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 Open the example run

Hands over

Never

Hands over

Never

Two modes, so private data and the open web never meet in one run

Hands over

Never

Hands over

Never

Product metrics are proposed, never invented

Retry failed payments by failure type

01Problem

02Goal

03Requirements

04Metrics

05Tracking

06Acceptance

07Open questions

Hands over

Never

Hands over

Never

Detectors

Orchestrator

Monitor

Draft only

Evidence on everything

Versioned and linked

Minimum context

Source authority

Feedback stays local

A visible profile

A run sees only what its requester may see

Confirmed

Supported

Hypothesis

Bring us one complex revenue problem.