DEV Community: sunny yuen

Hiring Is a Black Box on Both Ends

sunny yuen — Mon, 14 Sep 2026 18:11:45 +0000

I've been on both ends of the same black box this year.

On one end: a veteran software engineer (6 years, full-stack, AI-native workflow) running an actual job hunt — 100+ applications submitted through a pipeline I built, with a fit score on every one. On the other end: employers, at least on paper, drowning — applications per open role up 111% since 2022, applications per recruiter up 412%, time-to-fill up 37% (Greenhouse's own benchmark data across 6,000+ companies).

Both sides are drowning. Both sides are trying to figure out the same two things, in opposite directions:

Employers: is this candidate a good fit — and can I even trust what they say?
Candidates: is this job the right fit for me — and will anyone actually look at me?

Here's what our first-party data — plus the 2026 research now landing on both sides — says about what's actually happening inside that box.

The black box on the employer end

The story the industry tells itself is that companies are being flooded with AI-generated applications and are fighting back with AI detection. That story is mostly wrong, and 2026's data keeps confirming it's wrong:

No major ATS ships AI-authorship detection. A 10-vendor survey (Workday, iCIMS, Greenhouse, Oracle, SAP, Lever, Workable, SmartRecruiters, Ashby, BambooHR) found zero platforms that analyze resume or cover-letter text for AI authorship. Greenhouse — the same vendor whose public policy calls AI-assisted writing "acceptable" — ships a paid fraud product ("Real Talent," with CLEAR identity verification and a fraud-risk score) that scores metadata and identity signals. It explicitly does not read your resume text for AI authorship.
Talent leaders rank fraud as the #1 challenge of 2026 — ahead of "lack of qualified talent" for the first time (GoodTime's annual survey, 500+ talent acquisition (TA) leaders). But notice what that means: the thing employers are bracing for is impersonation and fabrication, not "a candidate polished their resume with Claude."
99.8% of TA teams are using, piloting, or planning AI agents themselves. The receiving side isn't building walls against AI. It's adopting AI and installing border control for liars.

So the line employers are actually policing is not "AI-assisted" vs. "human." It's "real" vs. "fabricated." And here's the twist that matters for anyone on the candidate side:

A real candidate, AI-assisted, is on the safe side of that line

The research keeps landing in the same direction:

Tailored AI-assisted resumes got 18% employer response in a 204-application field experiment vs. 10% for generic AI and 31% for fully human-written. Tailoring nearly doubled generic AI's response rate. Generic AI is the worst-performing format of anything tested.
When AI noise floods a channel, employers don't stop discriminating — they re-price toward harder-to-fake signals. In one large field study, after an AI cover-letter tool launched, the correlation between letter quality and callbacks fell 51% — and employers shifted weight to work history, the one thing you can't prompt-engineer.
Fabrication is the real disease: a controlled study of automated LLM hiring pipelines found unsupported claims (fabricated credentials, inflated qualifiers, invented experience) in 96.7% of outputs. That's what the receiving side is actually afraid of. And they're right to be.

The conclusion I've drawn from running my own pipeline through all this: the problem with AI-assisted applications isn't that they're AI-assisted. It's that most of them are ungrounded. The receiving side isn't scanning for Claude. It's scanning for liars. A candidate whose claims are verifiable is solving the actual problem employers are paying CLEAR and IPQualityScore to solve. A candidate with a generic AI resume is just adding to the noise both sides are drowning in.

What my own data says — and doesn't

Here's the honest part. My pipeline (100+ applications, each scored for fit, each tailored): 3 phone screens, 0 technical interviews, 15 rejections so far. If AI-assisted tailoring were a magic bullet, those numbers would look different. They don't.

Why? Because hiring is a black box on both ends:

From the employer side, they can't easily tell a grounded, evidence-backed candidate from a confident-sounding fabrication — so they fall back on human review friction, identity checks, and slower processes that treat everyone like a suspect.
From the candidate side, you can't see why you were rejected. Was it the AI-assisted approach? Calibration? The market? Comp band? Just volume and time? Every one of those produces the exact same funnel numbers from the inside. More applications doesn't resolve it.

The industry's own data suggests the answer isn't "stop using AI," either. The receiving side pays a premium for the thing AI can't fake — verified history, real work, provable claims. And it pays a trust discount on everything else. Even on proof that's genuine: one study of 1,380 HR professionals found a real digital credential was trusted less than the same certificate shown in person.

What we're changing because of this

This isn't commentary from the sidelines — this is my own pipeline, and here's what changed:

Shortlist calibration over volume. The evidence says fit-calibrated, tailored submissions outperform volume; the pipeline now optimizes for the strongest-fit, most-evidence-backed applications per day, not raw throughput.
Evidence-forward over claim-forward. Every claim the pipeline generates carries the evidence behind it (public repo, shipped work, queryable endpoint) rather than polished prose alone. If the receiving side is policing fabrication, the winning side of that line is the verifiable one.
Disclose the mechanism, not the tool. A recruiter's own AI can query a candidate endpoint that returns structured, evidence-grounded claims. The response rate data says that's the direction the channel is moving; the fraud-product data says the receiving side is explicitly building for it.

The takeaway

Hiring in 2026 is a black box on both ends, and both ends are panicking about the same thing in opposite directions:

Employers are building fraud infrastructure, not AI detection. The line they're policing is trust, not tooling.
Candidates are burning out on a channel where generic AI output is now the worst-performing format, not the best.

The unglamorous conclusion: the AI-assisted candidate isn't fighting the system. The ungrounded one is. And that line is now enforced by paid fraud infrastructure. Which means the question isn't whether you used AI. It's whether what you submitted is true.

Job-hunt figures are first-party, from the pipeline I run; market figures are attributed to their sources in the text.

The Decision Runtime: Bounded Authority for the Chief of Staff Control Plane

sunny yuen — Mon, 31 Aug 2026 13:00:00 +0000

Part one of this series argued that workplace AI needs a control plane — a Chief of Staff that triages, remembers, and governs, instead of a pile of siloed point-solution agents. That piece described the shape of the thing. It didn't answer a harder question: how does a Chief of Staff earn the right to act on your behalf, and prove afterward that it stayed inside that right?

That question is what shaped the Decision Runtime's design. Not "give the agent more tools" — tools were never the constraint. The constraint was that acting on someone's behalf without a provable record of authority isn't delegation, it's just risk with extra steps. Everything below is a design decision made in service of one goal: an agent can do real work, and every piece of that work can be traced back to exactly what allowed it.

1. The gap the design closes

A Chief of Staff that can act but can't account for what it did, why, or under what authority isn't a Chief of Staff — it's a very fast intern with no paper trail. The design had to answer three questions any real operator would ask walking in cold, before it earned the right to touch anything consequential:

What requires owner attention right now?
What did the agent already do without me?
What outcome is still expected, and did it land?

A system that can't answer those on demand isn't trustworthy at any level of autonomy, bounded or not — so the runtime's job is to make those three questions always answerable from durable state, not from someone's memory of what the agent was supposed to be doing.

2. Bounded autonomy, not autonomy

The obvious design would be a single permission flag: this agent may act, or it may not. We rejected that shape because real operating decisions aren't binary. Something can be worth doing without needing a human told about it. Something else can be worth flagging without touching priority at all. Collapsing those into one yes/no either over-grants (the agent silently reprioritizes things it should only ever report) or under-grants (every trivial action waits on a human because the one flag covering it also covers something consequential). So every unit of work the runtime tracks carries three independent authority signals instead of one:

execution:       act
attention:       inform
priority_effect: within_current_policy

The second, harder design decision: the runtime itself decides none of this. It doesn't grant authority — it records and enforces whatever authority an external operating policy already grants. That line exists because a workflow-neutral runtime that also opined on what agents should be allowed to do would stop being reusable; the moment it bakes in one consumer's judgment about acceptable risk, every other consumer inherits that judgment too. A consumer defines the policy; the runtime's only job is making it impossible to quietly exceed it.

The consequence of designing it that way: the operating mode is governed, not irreversible. A deployment can start a policy conservative and expand it only through a reviewed change, and narrowing it back down is a policy edit, not a rollback or a rewrite. That reversibility is what makes "bounded" an actual property of the system rather than a one-time promise made at launch and never revisited.

3. Attributable work

The cheap way to build this would be a log line per action: timestamp, actor, message. We didn't do that, because a log line answers "something happened" but not "was this actually authorized, and by what chain of reasoning." A prose log can be edited, is easy to leave incomplete under time pressure, and doesn't let you traverse from an outcome back to the exact evidence and approval that produced it — you can only read it linearly and hope the relevant line is in there.

So every event, work item, action attempt, approval, result, and artifact is instead a typed, append-only record connected by explicit edges: what caused it, who or what performed it, which tool invocation ran, what evidence it used, what decision or approval it required, and what it produced. And identity is never a field the caller fills in — the authenticated principal, the effective actor, and the authorization decision are derived server-side, on purpose, so a compromised or careless caller can't self-assign a different identity than the one it authenticated as.

The design bet: a graph you can traverse answers "why did this happen, who or what performed it, and under which authority" on demand. A log you can only grep answers it only if you already know what you're looking for.

4. Portfolio-level reasoning

Part one named the failure mode this is designed against: agent sprawl, where every system gets its own point-solution agent with no shared context. The design response is that the runtime deliberately doesn't care which repository or service an event came from — a subject is just a namespaced type and ID, not "the GitHub domain" or "the deploy domain." That's what makes one reasoning chain possible across systems that share nothing else:

signal → affected bet → current constraint → recommendation → action

A failed deployment, a customer reply, and an open PR can all bear on the same operating decision even though they originate in three unrelated systems. The alternative — a purpose-built integration between every pair of systems that need to inform each other — doesn't scale past a handful of systems; a shared, typed substrate is the design choice that avoids that combinatorics problem entirely.

5. A real Decision Queue

A manually maintained queue rots two ways: someone forgets to add something that mattered, or nobody prunes what stopped mattering, and the queue turns into noise the owner learns to skim past. Both failure modes come from the same root cause — the queue is a second copy of state that a human has to keep in sync with reality by hand.

The design fix is to make the queue a projection of runtime state instead of an independent list: rebuildable from durable records, not hand-curated, surfacing only what the records say genuinely needs the operating owner —

Approval required
A material assumption changed
A priority change was proposed
Protected attention is needed
A review deadline was reached

Everything else stays out of the queue by construction. No one has to remember to filter it, because there's no separate list to fall out of sync with the thing it's supposed to represent.

6. Closed feedback loops

The easiest design mistake here would be treating a decision as finished the moment the action fires — which is exactly how automation quietly drifts from reality: an assumption goes stale, nobody re-checks it, and the system keeps acting on it anyway because nothing in the design forces a look back. So a decision in this model isn't a point in time, it's a loop that has to close:

decision → action → observed result → metric or assumption update → continue, reconsider, or escalate

Closing the loop is also what keeps the improvement inside the right boundary. The Chief of Staff can get better at operating within a policy by learning from observed outcomes — but changing the policy itself stays outside that loop, under Git review and owner approval, not inside a model's own judgment about what it should be allowed to do next. Those are deliberately two different mechanisms, not one blurred together.

7. Event-driven operation

The real test of the design in sections 1-6 is whether a new trigger source needs new runtime logic, or just a new registration. A GitHub dispatcher that turns a repository event directly into attributable work is one instance of the pattern:

GitHub event → Chief of Staff review work item → exact-head verification → GitHub MCP actions → review result → runtime attribution and outcome

Nothing about that chain is GitHub-specific at the runtime layer — the event, the work item, the attempt, and the outcome are the same typed primitives every other section describes. The same pattern extends to a deployment, an incident, a schedule, or a Slack message without touching the runtime itself, only adding the typed registration for that new source. If a new trigger required new runtime code, that would mean the earlier design decisions weren't actually general — this is the part of the design meant to prove that they are.

What it is not

Not a store for private model chain-of-thought.
Not a replacement for the agent's own memory layer.
Not a general-purpose job queue.
Not a source of new authority — it enforces authority, it doesn't grant it.
Not a replacement for GitHub issues or PRs.
Not the agent making decisions by itself.

It stores structured reasoning products — facts, evidence, assumptions, recommendations, classifications, decisions, and outcomes — not hidden internal reasoning.

Why this matters

The real shift isn't "the agent can now do more." It's that the Chief of Staff stops being purely reactive. It can hold a durable understanding of what matters, notice when reality changes, act within a policy someone else set and can audit, and bring back only the decisions that actually need a human — instead of every decision, or none of them.

Open source, same repo as part one: github.com/yuens1002/openclaw-control-plane. The Decision Runtime API, its MCP bridge, and the architecture/authentication docs are all public. If you're building something similar, I'd genuinely like to hear where the authority model breaks down in your use case — that's exactly the kind of edge case a workflow-neutral runtime needs to survive.

Beyond the Chatbot: Why the Future of Workplace AI Needs a "Chief of Staff" Control Plane

sunny yuen — Fri, 14 Aug 2026 19:09:02 +0000

Today, teams deploying AI across business operations keep hitting the same wall: agent sprawl. Organizations end up with siloed AI tools — one for customer support, another for lead scoring, another for code verification — operating in isolation with fragmented context, unpredictable failure modes, and zero centralized governance.

To build reliable business automation, we need to rethink the architecture. The fix isn't a bigger, monolithic model; it's establishing a control plane that operates like an AI Chief of Staff.

1. The problem: AI workers without central governance

In a traditional organization, you wouldn't hire five specialized contractors and let them work without coordination, shared context, or executive oversight. Yet that's often exactly how multi-agent architectures get built today.

When specialized agents run without a central control plane, you get:

Context fragmentation — knowledge trapped inside point solutions instead of shared across the client lifecycle.
Uncontrolled side effects — without centralized policy checks, automated tasks risk making unauthorized updates to CRMs, databases, or client-facing channels.
Operator fatigue — humans forced to babysit multiple distinct interfaces instead of reviewing high-signal, decision-ready briefings.

2. The architecture: control plane vs. execution plane

The fix is a clear architectural separation between the control plane (governance, triage, state) and the execution plane (domain-specific workers).

The control plane doesn't execute line-level tasks itself. Like a Chief of Staff, it handles four core responsibilities:

Intake triage & routing — ingests incoming events (webhooks, scheduled triggers, user instructions) and dispatches generic event envelopes to the right domain worker.
State & cross-functional memory — maintains historical context, task logs, and outcome tracking across disjoint workstreams.
Human-in-the-loop (HITL) governance — evaluates risk boundaries. Read-only tasks execute autonomously; state-mutating actions (contract generation, production deploys, financial transactions) route through approval gates.
Executive synthesis — filters out execution noise, delivering concise, actionable briefings to the operator via Slack, email, or a centralized dashboard.

In this architecture, the three example workers are a starting illustration, not a prescription — swap in whatever domains your business actually runs: an Acquisition Worker (intake & scoring), a Support Worker (ticket triage & response), and a Growth Analytics worker (telemetry & logs) are common enough to stand in for the pattern, but the control plane doesn't care what's downstream as long as it speaks generic event envelopes and MCP tool calls.

3. Connecting the fleet: standardized protocols (MCP)

A control plane is only as good as its interfaces. Leaning on the Model Context Protocol (MCP) and a workflow-neutral runtime shell gets you:

Decoupled domain workers — specialized workers (sales intake, customer support, bookkeeping) can be added, updated, or replaced without touching core database schemas or routing logic.
Standardized tool access — third-party integrations (CRMs, Stripe, cloud hosting, Git workflows) are exposed as structured tool endpoints with built-in audit logs and rate limits.
Closed-loop feedback — analytics workers track performance and attribution metrics, feeding operational data back to the control plane to continuously refine prompt strategies and scoring heuristics.

4. From theory to infrastructure: open-sourcing the foundation

Talking about control planes and agent swarms is easy; operationalizing them in production usually breaks down at the infrastructure layer — fragile Docker builds, environment drift, unverified runtime setups.

To fix that, I've open-sourced the foundation layer: OpenClaw Control Plane — a workflow-neutral TypeScript monorepo that puts source-controlled operating discipline around an OpenClaw instance on Railway.

To be precise about what it is: OpenClaw itself already ships /setup, login, and the /openclaw Control UI, and there's an existing community Railway template for the fastest generic install. This repo isn't a replacement for either of those — it's the governed install path around them, for teams that want more than a quick demo:

A pinned, auditable dependency on the upstream OpenClaw Railway wrapper, with weekly update detection and no silent auto-upgrades to production.
Live Railway proof checks — source repo, runtime settings, domain port, deployment source, /setup, /setup/healthz, and /openclaw all get verified, not assumed.
A workflow-neutral starter-kit boundary — no baked-in client pipeline, connector, database, or secret assumptions.
A clean place to define setup-profile conventions that private agency/client repos can build on to automate provider, channel, plugin, and workflow attachment.
Handoff and verification discipline for repeatable client onboarding.

It's early — M1 foundation work, with the default API and worker runner starting empty of registered workflows on purpose. Production connectors and client-specific assumptions are intentionally out of scope for this layer.

5. What's next on the roadmap

This open-source template is the foundation — the baseline runtime where the "Chief of Staff" lives. Coming next:

Modular domain worker specs — reference implementations for inbound sales intake, acceptance-criteria (AC) verification, and analytics attribution.
Standardized MCP tool bridges — pre-built connectors for CRMs, billing systems, and client infrastructure.
Operator dashboards — lightweight HITL interfaces for single-tap task approvals and telemetry monitoring.

Build in public: check out the repo, spin up a test instance on Railway, and let me know what you'd want a "Chief of Staff" control plane to handle first.

I made my résumé something a machine can read fairly — here's how it's built, and how to stand up your own

sunny yuen — Tue, 02 Jun 2026 13:10:02 +0000

A model reads my work before any person does, and I had no say in what it concluded from a frozen PDF. I couldn't change that a machine reads first. I could change what I put in front of it. So I did — and here's the build.

The shape of it

A small backend exposes a profile as an API — GET /info, POST /query (grounded answers + sources), POST /match (fit score), POST /resume (tailored). It also speaks agent: an MCP endpoint and an A2A agent-card for machine callers.
A web front (React + a tiny Hono server) renders it as a conversation for people, and as JSON-LD + llms.txt + a crawlable <noscript> for machines — so a non-JS fetch isn't an empty shell.
Nothing hardcodes me. Identity comes from /info. Fork the front, point two env vars at your backend, and it's yours. Both repos are MIT.

Why I bothered

I'd rather be queryable and checkable than impressively static. The whole thing is grounded — ask it "what's the evidence?" and it answers with commit counts, tests, and live endpoints; the dated reasoning is browsable too. (The resume-agent repo links to a live instance if you want to poke it.)

If you want to build one

The smallest version is about ten minutes — fork the front, point it at any backend (even a stub /info), and deploy. That's a real, queryable node. If you stand one up, I'd genuinely like to see it. You don't have to agree with where I think this goes; a working node is its own statement.

This is the candidate side of a two-sided thing — an open protocol for hiring. The employer-side reference and the spec are open too, if the architecture pulls you further.

The repos

resume-agent — the candidate-side backend, the profile-as-API. Links to a live instance for a demo: https://github.com/yuens1002/resume-agent
resume-agent-web — the forkable web front: https://github.com/yuens1002/resume-agent-web
open-employment-protocol — the reconciler that sits between the two sides: https://github.com/yuens1002/open-employment-protocol
employer-agent — the employer side, scaffolded as a call to build: https://github.com/yuens1002/employer-agent

Built with a lot of AI help, deliberately unnamed — it wasn't one tool, it was the compounded work of everything that came before mine. Which is the kind of AI I'm building on: something you extend and pass forward.

You Don't Have to Learn Hermes From Scratch — I Brought My Existing Skills In

sunny yuen — Thu, 28 May 2026 21:41:06 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

I Didn't Start With Hermes

Six months ago I started building a set of agent skills and personas for how I build software. Not generic prompts — opinionated role files. A /backend-architect that owns schema and recommendation logic. A /test-engineer that writes Vitest coverage and flags weak acceptance criteria. A /project-manager that maintains planning docs and closes iterations cleanly.

These roles have evolved across multiple projects. They have layering rules, discovery checklists, inheritance from a base engineering discipline file. They produce consistent, reviewable work because they're scoped — the backend architect doesn't touch test files, the test engineer doesn't redesign the schema, each persona has a defined mandate and exits cleanly.

When I heard about Hermes Agent, my first instinct wasn't "let me learn a new system." It was: can I run my existing system inside this?

The answer is yes. That's what this article is about — what it looks like to bring a mature workflow into Hermes, what you gain, where it breaks down, and what I'd do differently.

What Hermes Is (and Isn't) to Someone Who Already Has a Workflow

Hermes is an LLM-agnostic orchestration layer. It has its own skill system, its own soul.md concept for persistent agent identity, built-in cron scheduling and MCP management. All of that is real and useful.

But it's also a runtime. If you have skills that work, you can bring them in.

I installed a local Hermes instance — few clicks, straightforward setup — and ran it inside VSCode's integrated terminal pointed at my existing persona files. No migration. No rewrite. My /backend-architect runs in Hermes the same way it runs in Claude Code.

Before settling on this, I'd tried a couple of other paths — a VPS instance with a Telegram interface for ideation, and attempting to build through a browser-based terminal. The VPS was fine for sketching ideas. The browser terminal made it clear that building production-grade tooling without proper local environment was the wrong path. Local Hermes in VSCode removed that friction.

The thing that surprised me: you don't have to choose between "learn Hermes natively" and "keep using what works." You can do both at once. Hermes becomes the runtime. Your skills stay the structure.

The Build: Production in 3 Days on a New System

The project I built with this setup is Brew Guide — a community coffee knowledge base exposed as a public MCP server. It logs real brew experiments, builds consensus recommendations from that data, and returns technique guidance (bloom timing, pour stages, agitation style) via 5 MCP tools. Production endpoint, no auth, live now.

I built it in 3 days — on Hermes, which I'd never used before.

That number is the point. Not because the build was simple (Neon Postgres, Prisma migrations, 55 passing tests, Railway auto-deploy, strict TypeScript throughout), but because I didn't spend those 3 days learning Hermes. I spent them building. The workflow did the heavy lifting on an unfamiliar runtime because the workflow was already mature.

The competition sprint — 7 deliverables including a scraper, technique JSONB on the schema, a landing page, and the competition article — reached "verified" on the first review pass. One iteration. That's the workflow functioning, not the AI being infallible.

What Breaks When You Switch Models

Here's the more interesting part, and I want to be honest about it.

During an earlier iteration, I ran the same skill set through a different model on the same codebase. Same persona files, same task scope, same Hermes orchestration. The goal: understand whether my workflow was portable across LLMs.

The observable failure mode was tool call adherence. The other model fumbled calls more often — retries, moments where it found its own path around the structured orchestration rather than following the skill specification. Tasks that took 30 minutes with Claude took most of a working day. The output required remediation: a Node version API call that crashed production, acceptance criteria tests that confirmed plumbing but not the scoring invariants the ACs required, docs that drifted from the code.

I want to be careful about what I can and can't claim. I wasn't using Hermes' native model adapters at the time — the skills were running through the same interface I'd built for Claude. So I can't say definitively whether the gap was model capability or a Hermes-model integration issue. Both are plausible.

What I can say: same instructions, same personas, dramatically different adherence to the spec. My skills were written and refined on Claude's way of parsing structured instructions. When you hand those same instructions to a model with different parsing behaviour, adherence degrades — and tool call reliability is the first thing to break.

This is the portability question Hermes is built to solve. It's a genuinely hard problem, and I didn't solve it. But surfacing where it breaks is the useful finding.

What I'd Build Differently

The gap I felt throughout came from one step I skipped: I never migrated my skills to native Hermes format.

Hermes has a soul.md concept — a persistent document that shapes agent identity across sessions. Think of it as the context your agent carries into every conversation: its values, working style, constraints. My skills work without it, but they're missing an anchor. A soul.md tuned to how I build — layering rules, persona boundaries, the engineering discipline that governs all my roles — would give Hermes native context that currently lives in my head, and make skills more robust across model handoffs.

The second missing step: model-specific skill validation. My skills assume Claude's instruction-following behaviour. A proper migration would test each persona against multiple model families and adjust language and structure where adherence breaks down. That's what "native Hermes skills" gives you — not just ported files, but skills validated against the runtime you're actually using.

The parts of Hermes where the DX is already smooth regardless: cron scheduling and hermes mcp add. Setting up the weekly coffee literature automation as a cron job was trivial. Connecting the production MCP endpoint to any client is one command. These infrastructure pieces are where Hermes earns its keep without needing any skill migration at all.

The Honest Verdict

Six months of evolved Claude skills beats Hermes' out-of-the-box defaults — for the way I specifically build software.

But that's the wrong comparison. The right question: does Hermes give you something you don't already have?

For me, two things.

LLM portability. The ability to run your skills against a local model, a different provider, without rebuilding anything. For production work with tight quality requirements, I want Claude's reliability. For experiments, local automations, cost-sensitive builds: Hermes makes the option real without a rewrite tax.

The infrastructure layer. Cron, MCP management, soul.md persistence. Not things you'd build for one project, but immediately useful once they exist.

What I'd tell a developer starting out: bring your existing workflow in first. Don't wait until you've learned Hermes natively before you build anything. Run your current skills, see what holds, see what breaks at the model boundary, and use that signal to decide what to migrate properly. The portability is the point — you don't earn it by starting over.

The project this workflow produced:

Web: brew-guide-production.up.railway.app — no login, try it now
MCP: https://brew-guide-production.up.railway.app/mcp
GitHub: yuens1002/brew-guide

Every Great Cup Starts with the Right Question — I Built the Community Behind the Answer with Hermes Agent

sunny yuen — Thu, 28 May 2026 21:29:01 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

Real brewing knowledge lives in human experience — in roaster guides, in community notes, in what a barista learned from last Tuesday's pour. It doesn't accumulate anywhere. Every brew is forgotten. Ask any AI and you get statistical averages: 93°C, 1:16 ratio, four minutes. Technically defensible. Practically generic. Worse still for rare origins where training data is thin.

Demo

For coffee drinkers

Visit brew-guide-production.up.railway.app. No account. No setup. No AI client required.

Pick your coffee origin, roast level, and brew method. What comes back isn't a generic recipe — it's community consensus: the grind, temperature, ratio, and brew time that real people have logged and rated for that origin, plus step-by-step technique guidance (bloom timing, pour stages, agitation style). If data is sparse for your origin, the confidence tier says so honestly and falls back to method defaults rather than making something up.

This is for the person who just picked up a bag of Kenyan peaberry and wants to know how to do it justice. It works for anyone who cares about their cup — no technical knowledge required.

For developers and AI clients

Connect to any MCP-capable client in one line:

https://brew-guide-production.up.railway.app/mcp

Ask your AI: "recommend a pour over for Ethiopian light roast." What comes back is a traceable community consensus object: brew parameters, a confidence tier (high/medium/low), the source brews that contributed, and method-specific technique guidance. You can see where the knowledge came from and how certain the system is — a fundamentally different epistemic object from an AI-generated recipe.

Code

GitHub: yuens1002/brew-guide

Five MCP tools — get_brewing_methods, recommend, log_brew, search_brews, compare_brew — over Streamable HTTP transport. Public, no auth required.

My Tech Stack

Layer	Technology
HTTP	Hono 4 + `@hono/node-server`
MCP	`@modelcontextprotocol/sdk` + `@hono/mcp` (Streamable HTTP)
Database	Neon Postgres + Prisma ORM
Runtime	Node 24, TypeScript strict, ESM
Tests	Vitest (55 tests, 0 errors)
Deploy	Railway (auto-deploy from `main`)

The recommendation engine is fully deterministic — no LLM on the hot path. computeBestBrew() fetches up to 50 recent brews, scores each against your request params (origin, method, roast, variety, grind), applies recency decay (linear 1.0 → 0.1 over 365 days) and source trust weights, takes the top 5, and builds consensus via weighted average (numeric fields) or weighted mode (categorical). Sub-100ms. Reproducible. Auditable.

The voting infrastructure is live (thumbs_up/thumbs_down on recommendations, brew_recommendation_links tracking which brews followed which recommendations). Vote weighting inside computeBestBrew is the one acknowledged gap — the checks-and-balances mechanism is designed, the math isn't wired yet. That's the next commit.

How I Used Hermes Agent

I built this in 3 days — on a system I'd never used before.

That's the headline, and it's what I want to explain. I didn't start from scratch on Hermes. I installed a local instance, ran it inside VSCode's terminal, and pointed it at persona files I'd spent six months building. Three role files govern the entire build:

/backend-architect — owns schema design, the recommendation engine, all DB logic
/test-engineer — owns Vitest coverage, catches weak ACs, flags regressions
/project-manager — owns planning docs, retrospectives, and this article

Each persona has a focused mandate and a defined exit condition. The backend architect doesn't touch test files. The test engineer doesn't redesign the schema.

What the workflow looks like in practice:

Write a plan with a deliverable table (D1–D7), each with owner, files, acceptance criteria, commit schedule
Hand each deliverable to the relevant persona
After each feature, the test engineer verifies coverage and flags gaps
Review report before merge

The competition sprint — scraper, technique JSONB, landing page, this article — reached "verified" on the first review pass. 55 tests, zero TypeScript errors, all deliverables complete. One iteration.

The previous iteration of this codebase was run on a different model through the same Hermes setup. Similar scope, same skill set, same orchestration. That iteration required production hotfixes (a Node version API crash on Railway), remediation of weak acceptance criteria tests, and took the better part of a working day. The gap in tool call adherence — the other model fumbling calls and finding workarounds around the skill spec rather than through it — was the visible failure mode.

Hermes as a runtime made that comparison possible without changing anything in the workflow. Same skills, same personas, different model. The portability is the point.

Beyond orchestration, Hermes added two things directly: cron scheduling for the weekly coffee literature automation (hermes-automation/), and hermes mcp add for connecting the production endpoint to any client instantly. That MCP management DX is genuinely smooth.

What I'd build differently next time: migrate the skills to native Hermes format with a soul.md as a persistent identity anchor. The skills work as-is, but validating them against multiple model families — adjusting language and structure where tool call adherence degrades — is the proper portability work I didn't have time for. That's the experiment this project sets up.