External-safe architecture overview

Hermes inside our custom business ERP

Hermes is an authenticated assistant layer embedded in a business operations app. It can answer page-specific questions, fill registered forms, start longer implementation work, and preserve an audit trail without exposing secrets or bypassing application controls.

Authenticated users only Server-side agent proxy Confirmation-gated writes No browser secrets Repo-aware work lanes

Plain-English summary

Think of Hermes as a context-aware copilot for an ERP screen. The browser shares only the current page context and registered safe controls. The server authenticates the user, rate-limits requests, and forwards the task to an isolated assistant runtime.

  • It sees structured page context, not raw unrestricted browser access.
  • It proposes actions through app-owned controllers, not direct DOM scripting.
  • It can work with code, issues, and pull requests through a controlled runtime.
  • It logs sessions, messages, action proposals, and task status for review.
System map

How Hermes relates to the app, data, and development workflow

The public names below are deliberately generic. They preserve the real architecture without disclosing internal product, customer, host, database, table, or repository names.

Hermes architecture diagram User connects to ERP UI, UI calls authenticated server proxy, proxy talks to assistant runtime and safe app services. Authenticated assistant path Operations user Logged in to ERP Text or voice turn ERP web application Dashboard pages Hermes chat drawer Registered forms + page data Authenticated API layer Auth, roles, ownership Rate limits + audit logs Safe action validation Assistant runtime Agent gateway Skills and tools Long-running tasks Safe action registry Allowed fields and buttons App-owned controllers Operational data context Read-only summaries Route, filters, visible rows Work products Issues, branches, PRs Tests and browser checks Structured app data Business records Read/write via app routes Analytics warehouse Read-only diagnostics Interaction history Code hosting Issues, branches, PRs Reviewable changes Related repositories Planning engine, channel sync, runtime infra Used for investigation and implementation
Capabilities

What Hermes can do

Hermes combines page-level awareness with a server-side agent runtime. Its abilities fall into four practical lanes.

Explain the current page Uses route, page title, selected text, visible summaries, filters, and safe data descriptors to answer questions about what the user is seeing.
Fill registered controls Can fill fields, pick options, toggle checkboxes, set dates, open approved modals, and click safe local buttons when a page registers those controls.
Handle text and voice turns Supports chat, one-turn voice transcription, spoken replies, streaming run updates, stop-run controls, and approval panels.
Route product changes Can turn clear requests or diagnosed bugs into issues, implementation branches, pull requests, tests, and review handoffs.
Ability How it works Safety posture
Page-aware help Receives a bounded page envelope: current route, title, selected text, visible state, and read-only page data context. Read-only
Form and filter fill Uses registered schemas and controllers. Simple exact-field requests can be planned by a deterministic app-side planner before the remote agent is called. Safe local
Persisted saves and status changes May be proposed only through existing app validation and route handlers. Confirmation required
Inventory, production, or destructive changes Remain behind explicit, visible user approval and app-owned confirmation flows. Destructive confirmation
Code and workflow changes Runs in an assistant runtime with repo checkouts, CLI tools, test tools, issue tracker access, and code-hosting workflows. Review-gated
Unsupported surfaces File upload, camera capture, raw drag/drop, credentials, schema changes, and broad bulk production mutations are not available unless a future page-specific controller allows them. Unsupported by default
Access model

What Hermes has access to

The access model is intentionally layered. The browser, ERP server, and assistant runtime have different information and authority.

Hermes access layers Diagram showing browser, server proxy, and assistant runtime access boundaries. Browser layer Can send Page path, title, selected text Registered field schemas Safe button descriptors Visible read-only summaries Cannot see Agent API key Code host token Server secrets Unregistered page controls ERP server layer Controls Authentication and authorization Session ownership checks Rate limits and capability gates Action validation Persists Conversations and messages Interaction events Task and PR metadata Assistant runtime Can use Generic ERP repo checkout Planning engine checkout Channel sync checkout Code host and issue tracker tools Read-only ops diagnostics Still constrained by App proxy auth and policy Review gates for code changes Confirmation gates for writes proxy run
Page context Route state, active filters, selected records, modal state, visible summaries, and bounded row previews.
Form schemas Field IDs, labels, types, allowed options, validation hints, read-only flags, and safe button definitions.
Conversation state User-scoped sessions, message history, run status, interaction logs, task records, and admin diagnostics.
Read-only data recipes Descriptors for app API, structured business data, analytics warehouse data, repo docs, and safe diagnostics.
Developer tools Code search, tests, browser verification, issue tracker, code hosting, and pull request workflows inside the runtime.
Runtime skills Domain-specific instructions for ERP support, planning, inventory, code review, operations diagnostics, and verification.
Action safety

How page actions are controlled

Hermes does not get general-purpose control over the browser. Pages opt in by registering their safe controls and data context. The app validates every proposed action before anything changes on screen.

Level 1 Safe local

Filter changes, draft text, local modal opens, read-only navigation, and other reversible screen-only edits.

Level 2 Clear intent

The user explicitly asks to send or submit a non-destructive draft, and the app still routes through normal handlers.

Level 3 Confirmation required

Persisted creates, updates, status changes, and business record saves need visible user approval.

Level 4 Destructive confirmation

Deletes, inventory mutations, production completion, sends, bulk changes, and irreversible actions require stronger confirmation.

Safe action proposal flow Hermes action requests are planned, validated, shown to the user, and executed by page controllers. User asks "Set this filter to open" Visible state Forms, fields, buttons Planner Exact match or agent proposal Validator Checks policy and schema Action panel Apply or ask No raw DOM Unregistered controls ignored No secret exposure Tokens stay server-side No silent writes Persisted effects are gated
Repository relationships

Generic repo and service names

These names map the implementation shape without revealing internal repository slugs. Use these labels when sharing the diagram outside the team.

Custom Business ERP The main web application. Owns the UI, authenticated Hermes proxy routes, page registration, app data APIs, and audit views.
Planning Engine A companion repository that produces forecasting, planning, and writeback outputs the ERP can display and explain.
Channel Sync Service A companion repository that syncs marketplace or channel data into the analytics layer used by dashboards.
Assistant Runtime The hosted Hermes gateway, persistent runtime state, installed skills, local workspaces, and messaging adapters.
Generic repository relationship diagram Custom Business ERP connects to planning engine, channel sync service, assistant runtime, data store, and code host. Custom Business ERP UI, app APIs, page-action bridge Hermes drawer and audit views Planning Engine Forecasts, plans, writebacks Channel Sync Service Sales, inventory, sync health Assistant Runtime Gateway, skills, tool access Code Host + Tracker Issues, branches, pull requests
User experience

Generic UI mockup

This mockup shows the embedded assistant pattern without any real operational data. The main ERP screen remains the primary workspace; Hermes lives in a right-side drawer with chat, voice, capability status, and action proposals.

Sharing notes

What this diagram intentionally omits

For external sharing, the artifact avoids internal repo names, customer or company names, actual database identifiers, production hostnames, API paths with business-specific semantics, real dashboard names, and any operational data.

Useful positioning: Hermes is best described as a governed assistant layer for a custom ERP, with server-side identity, policy, action validation, and repo-aware implementation lanes.

Internal category External-safe label
Main app repository Custom Business ERP
Planning/forecasting repository Planning Engine
Channel data sync repository Channel Sync Service
Hermes hosted service Assistant Runtime
Structured database systems Structured App Data / Analytics Warehouse
Development workflow tools Code Host + Issue Tracker

Single-file HTML artifact. No external scripts, fonts, images, or network calls are required to view it.

← Back to the full portfolio