hermes - 💡(How to fix) Fix Provide first-class artifact support: built-in skill or tool that delegates artifact builds to a focused subagent [1 participants]

Problem

Producing high-quality interactive artifacts (Claude.ai-style HTML pages with consistent design system, runtime API, image sourcing) is currently fragile when handled inline by the main agent:

• Artifact builds are token-heavy (1000–2000 lines of HTML), polluting the main conversation
• Once context grows, the main agent starts ignoring artifact-build instructions (template, runtime references, palette rules) — degraded outputs
• The user's main conversational thread gets buried under HTML dumps
• Build steps (research → image search → compose → validate) compete with conversational tasks for context budget

The hosted Claude experience handles this by running artifact builds in a separate context window — focused, fresh, with only the build-specific instructions and tools. The main agent stays clean.

Hermes already has all the primitives:

delegation:
  orchestrator_enabled: true
  max_concurrent_children: 3
  child_timeout_seconds: 600
  inherit_mcp_toolsets: true

…and `hermes_cli/profiles` supports per-profile SOUL/skills/tools. What's missing is a packaged, opinionated artifact-builder pattern that uses these primitives.

Proposal

A bundled, optional artifact-builder profile + corresponding skill that:

1. Defines a focused agent (SOUL.md = "I build polished interactive HTML artifacts. Nothing else.")
2. Loads only the tools needed for artifact builds (file write, web search, image search, browser if available)
3. Has a curated design-system spec (CSS palette, runtime API, sensible templates) — could be optional / pluggable
4. Returns a structured artifact event (path / url / type / title) rather than free-form text
5. Times out cleanly and reports failures back to the orchestrator

Main agent gains a build_artifact(spec) tool / skill call that delegates to this profile.

Returned event shape

Suggested:

{
  \"type\": \"artifact\",
  \"artifact\": {
    \"path\": \"/srv/workspace/artifacts/<slug>.html\",
    \"url\": \"http://<host>/artifacts/<slug>.html\",
    \"title\": \"...\",
    \"contentType\": \"text/html\",
    \"version\": 1
  }
}

This event shape is what dashboard UIs (hermes-workspace, etc.) can listen for to render artifact cards inline natively — separating "agent emits an artifact" from "chat happens to contain raw HTML".

Why this matters

• Artifacts are increasingly the primary output format for agents in interactive use cases (recipes, dashboards, prototypes, visualisations).
• Users with smaller / cheaper models (Kimi via Bedrock, Gemini Flash, etc.) experience the most degradation when artifact builds run inline — the focused-subagent pattern would actually unlock those models for high-quality artifact output.
• It's the architectural primitive that makes UI features like Workspace's artifact-rendering tab actually consistent.

Adjacent

Filed hermes-workspace#PLACEHOLDER requesting inline artifact rendering on the UI side. The two together would give Hermes a coherent artifact story end-to-end.

Happy to contribute

If this direction has support I'd put up a PR — bundled profile + skill + tool wiring. But this is an architectural addition, so wanted to file the issue first.