The Agent Runtime Should Not Own the Product

I am setting up a Hermes agent as a personal shopper for my wife.

The scope is deliberately narrow: can an agent learn enough about one person, her wardrobe, her preferences, and the situations she dresses for to become genuinely useful?

Hermes is a good place to answer that question. It gives me a conversational surface, memory, tools, scheduled work, and enough flexibility to change the agent while I am still discovering what the agent should do.

The project has nevertheless started producing architecture questions.

Where should photographs and garment metadata live? Is a preference mentioned in conversation part of agent memory, or should it become structured product data? How would a mobile interface retrieve the wardrobe without depending on the internals of the agent runtime? How would I distinguish a crashed request from a bad recommendation?

I am not answering those questions by replacing Hermes. I am using them to form a hypothesis about a possible architecture if the experiment ever outgrows its current runtime.

The central constraint is already clear:

The agent runtime may produce decisions, but it should not become the sole owner of product truth.

Hermes is the experiment, not a temporary inconvenience

It would be easy to call the current setup a prototype and immediately design the "real" system behind it. That would miss what Hermes is doing.

The hard part of a personal shopper is not storing garments in a database. It is discovering what a useful recommendation requires.

Does the agent need explicit style rules, examples of accepted and rejected outfits, or both? How much context should it ask for before answering? Which preferences are stable? When should it admit that the wardrobe does not contain a good option? Can it explain a recommendation without inventing confidence?

Hermes lets me change these behaviors while the model is still unsettled. Conversations expose missing knowledge. Failures suggest new tools or guardrails. Repeated cases can become evals.

Moving to another runtime before that behavior is understood would give me more infrastructure around an unstable idea.

The possible target architecture therefore is not a roadmap. It is a decomposition I can test against the pressure created by the current experiment.

A possible architecture beyond one runtime

If the personal shopper eventually needs a dedicated app and stronger data guarantees, this is the architecture I would investigate today:

| Capability | Candidate | Responsibility | | --- | --- | --- | | Mobile experience | Expo / React Native | Chat, wardrobe views, image capture, outfit feedback, notifications | | Application backend | Convex | Application API, business rules, realtime synchronization, rate limits | | Canonical data | Convex DB | User profile, garments, outfits, occasions, purchases, returns, structured preferences | | Images and files | Convex Storage | Garment photos, outfit images, product screenshots and their metadata | | Identity and access | Convex Auth or Clerk, enforced by Convex | Session identity and authorization over wardrobe data and agent tools | | Agent runtime | Mastra or Eve | Reasoning, workflows, tool execution, working memory, guardrails, traces and eval hooks | | Model interface | Vercel AI SDK | Model access, tool calling and streamed responses between the app and agent layer | | Software health | Sentry | Mobile crashes, backend errors, failed requests and performance | | Product behavior | PostHog | Feature use, repeated engagement, funnels and session-level behavior | | Agent quality | Runtime traces plus evals | Recommendation quality, tool correctness, latency, cost and regressions | | Deployment | Vercel plus managed services | Delivery of the web-facing components and operational configuration |

This table is deliberately about responsibilities rather than brands.

Convex is one candidate for the application and data layer. Mastra and Eve are two candidates for the agent runtime, not two components I would install together. Sentry and PostHog observe different failure domains. The AI SDK helps with model interaction and streaming but does not own application state.

The names can change. The boundaries should change only when evidence shows that they are wrong.

Product state needs a life outside the conversation

The wardrobe is not a transcript.

A garment has an identity, images, attributes, history, and relationships to outfits and occasions. A preference may begin as a sentence in a conversation, but some preferences eventually need explicit representation. "She disliked this recommendation" is an interaction. "She never wears these shoes for long walks" may become durable product knowledge, with provenance and a way to revise it.

This is why memory is not state.

Agent memory helps the model continue its work. Canonical data records what the application is prepared to treat as true. The difference affects validation, authorization, deletion, export, and correction.

It matters even in a single-user experiment because the data is personal. Wardrobe photographs, purchase history, body-related preferences, and private conversations should not become an opaque bundle that only one runtime knows how to interpret.

A separate application layer would let the agent request a wardrobe through narrow tools rather than direct database access. A tool such as findGarmentsForOccasion could enforce user scope, return a controlled schema, and record which data influenced the recommendation. The runtime could change without changing the identity of the garments or the access rules around them.

That is a stronger form of portability than a generic wrapper around two agent frameworks.

Mastra and Eve should compete on behavior

I do not yet know whether Mastra or Eve would be the better runtime.

Mastra appears closer to a conventional production baseline. Eve is interesting for persistent agents, skills, subagents, and durable execution. Comparing their feature lists would still leave the important question unanswered: can either preserve the behavior that made the Hermes agent useful?

The Hermes phase can produce the test set for that decision.

A good recommendation, a bad recommendation, a missing-data case, a tool failure, an ambiguous occasion, and an attempted action that requires confirmation can all become evaluation scenarios. Each runtime can then be measured against the same expectations:

• Did it select the correct tools and arguments?
• Did it respect the boundary between retrieved facts and model inference?
• Did it ask for missing information instead of fabricating it?
• Did it preserve the approval boundary around consequential actions?
• What latency and model cost did the behavior require?
• Could the workflow recover after a tool or model failure?

At that point, changing runtime is no longer a preference disguised as architecture. It is a migration with observable acceptance criteria.

Without those evals, a more sophisticated framework could make the system look more mature while silently making the personal shopper worse.

Three systems can be healthy while the product is wrong

The target architecture also needs more than one kind of observability.

Sentry can report that the Expo app crashed while an image was uploaded, or that a Convex function failed. That is engineering observability.

PostHog can show whether the wardrobe was completed, which interactions are repeated, where the experience is abandoned, and whether usage continues over time. That is product analytics.

Agent traces and evals can show which context was retrieved, which tools ran, how the answer changed after a model update, and whether the recommendation met the behavioral standard. That is agent observability.

One cannot substitute for another.

An application can have perfect uptime while the agent gives poor advice. The agent can pass offline evals while the interface makes the workflow too tedious to use. Product analytics can expose abandonment without revealing whether the cause was latency, a crash, or an irrelevant recommendation.

The architecture needs separate signals because these are separate failures.

It does not need every dashboard today. For one user, logs, explicit feedback, and a small eval set may be enough. Sentry becomes useful when failures are no longer visible directly. Product analytics becomes meaningful when there is enough repeated behavior to measure. The boundary should exist before the tooling becomes necessary, but the integration can wait for the pressure.

The architecture is a hypothesis, not a destination

The easiest mistake would be to turn this diagram into a backlog.

Expo, Convex, Mastra or Eve, the AI SDK, Sentry, and PostHog together describe a plausible product architecture. Installing all of them would not prove that the personal shopper needs them.

Hermes currently owns more responsibilities because that keeps the experiment cheap and legible. Splitting those responsibilities too early would create APIs, schemas, synchronization, credentials, deployments, and failure modes before the behavior is stable enough to justify them.

I would move a responsibility only when the current arrangement creates a concrete limit.

Canonical wardrobe data should move when conversational memory can no longer provide reliable ownership and correction. A dedicated app should appear when the interface constrains use. A different agent runtime should be considered when evals show a need for execution guarantees, integration, or scale that Hermes should not provide. External observability should arrive when direct inspection stops being enough.

This keeps the technical ambition honest. The diagram records where responsibilities could live. It does not claim that they must all exist now.

The purpose of the Hermes personal shopper is still to learn whether the agent can help my wife make better decisions with the clothes she owns.

If it succeeds, I will have both useful behavior and evidence for separating the system. If it does not, a larger architecture would only have made the same answer more expensive.

The next step is not to leave Hermes. It is to make the current agent good enough that any future architecture has something specific to preserve.