lhumina_code/home
22
0
Fork 0
Code Issues 14 Pull requests Projects Releases Packages Wiki Activity Actions

Hero OS AI & Service Integration — Master Roadmap #38

New issue
Open
opened 2026-03-18 17:24:39 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-03-18 17:24:39 +00:00
Owner
Copy link

Vision

Every Hero service exposes its capabilities via OpenRPC. The AI layer intelligently routes user intent — using cheap models for simple operations and powerful models for complex reasoning. All derived from a single source of truth: the OpenRPC spec.

Architecture End State

User (Hero OS UI)
  │
  ├─ Simple intent ("show contacts")
  │   → hero_aibroker → small model (mercury2) → generated Python code → service
  │
  └─ Complex intent ("compare Q1 vs Q2 meetings and draft a summary")
      → hero_shrimp → big model (Claude/GPT-4o) → MCP tool calls → services

hero_aibroker = intelligent routing broker:

  • Routes to cheap vs expensive models based on intent complexity
  • Generates Python clients from OpenRPC specs (#18)
  • Manages API keys, rate limits, cost control
  • NOT an MCP aggregator (that moves to shrimp, #36)

hero_shrimp = AI agent:

  • Handles complex multi-step reasoning
  • Spawns MCP bridges directly (Claude Desktop pattern)
  • Manages conversation state, memory, tools
  • Context-aware (passes user's workspace to tools)

Every service = OpenRPC + auto-MCP:

  • HeroRpcServer auto-injects /mcp from OpenRPC spec (#27)
  • Health, discovery, Unix socket (4-pillar standard, #34)
  • Python client auto-generated for code-gen path (#18)

Roadmap — Ordered by Dependencies

Phase 1: Foundation (current)

Issue Title Status Dependencies
#34 4-pillar standard (OpenRPC+MCP+Health+Socket) ~95% done —
#27 Unify server lifecycle (HeroRpcServer) Active (Timur) —
#37 Fix preflight errors in hero_rpc Filed —

Phase 2: Stabilization

Issue Title Status Dependencies
#30 Deprecate OServer → HeroRpcServer Open #27
#35 Context creation fix Open —
#29 Standard tests + E2E harness Open #27
#28 Dioxus Bootstrap migration Open —
#32 AI SSE streaming (word-by-word) Open —

Phase 3: AI Intelligence

Issue Title Status Dependencies
#36 Clean MCP architecture (shrimp direct, aibroker LLM-only) Filed #34
#18 OpenRPC-driven Python code generation Open #27 (OpenRPC on all services), #36 (aibroker role clarified)

Phase 4: Polish

Issue Title Status Dependencies
#33 Compute island: TFGrid connect Open —
— Intent-based routing in aibroker Future #18, #36

Design Principles

  1. OpenRPC = single source of truth — MCP tools, Python clients, SDKs, docs, discovery all derived from it. Same philosophy as OSIS generating from OTML schemas.
  2. Right tool for the job — Small models for simple operations (fast, cheap), big models for complex reasoning (accurate, expensive). Aibroker routes intelligently.
  3. Standard patterns everywhere — Every service uses HeroRpcServer, every service gets MCP, every service gets a Python client. No special cases.
  4. Context-scoped by default — User's active workspace (Geomind, Default, etc.) flows through to every tool call.

Key Repos

Repo Role
hero_rpc (hero_service crate) Server framework: HeroRpcServer, HeroUiServer, lifecycle
hero_aibroker Intelligent LLM routing + Python code generation
hero_shrimp AI agent + MCP tool management
hero_inspector Service discovery, docs, MCP gateway
hero_services Deployment orchestration, bridge scripts
## Vision Every Hero service exposes its capabilities via OpenRPC. The AI layer intelligently routes user intent — using cheap models for simple operations and powerful models for complex reasoning. All derived from a single source of truth: the OpenRPC spec. ## Architecture End State ``` User (Hero OS UI) │ ├─ Simple intent ("show contacts") │ → hero_aibroker → small model (mercury2) → generated Python code → service │ └─ Complex intent ("compare Q1 vs Q2 meetings and draft a summary") → hero_shrimp → big model (Claude/GPT-4o) → MCP tool calls → services ``` **hero_aibroker** = intelligent routing broker: - Routes to cheap vs expensive models based on intent complexity - Generates Python clients from OpenRPC specs (#18) - Manages API keys, rate limits, cost control - NOT an MCP aggregator (that moves to shrimp, #36) **hero_shrimp** = AI agent: - Handles complex multi-step reasoning - Spawns MCP bridges directly (Claude Desktop pattern) - Manages conversation state, memory, tools - Context-aware (passes user's workspace to tools) **Every service** = OpenRPC + auto-MCP: - `HeroRpcServer` auto-injects /mcp from OpenRPC spec (#27) - Health, discovery, Unix socket (4-pillar standard, #34) - Python client auto-generated for code-gen path (#18) ## Roadmap — Ordered by Dependencies ### Phase 1: Foundation (current) | Issue | Title | Status | Dependencies | |-------|-------|--------|--------------| | **#34** | 4-pillar standard (OpenRPC+MCP+Health+Socket) | **~95% done** | — | | **#27** | Unify server lifecycle (HeroRpcServer) | Active (Timur) | — | | **#37** | Fix preflight errors in hero_rpc | Filed | — | ### Phase 2: Stabilization | Issue | Title | Status | Dependencies | |-------|-------|--------|--------------| | **#30** | Deprecate OServer → HeroRpcServer | Open | #27 | | **#35** | Context creation fix | Open | — | | **#29** | Standard tests + E2E harness | Open | #27 | | **#28** | Dioxus Bootstrap migration | Open | — | | **#32** | AI SSE streaming (word-by-word) | Open | — | ### Phase 3: AI Intelligence | Issue | Title | Status | Dependencies | |-------|-------|--------|--------------| | **#36** | Clean MCP architecture (shrimp direct, aibroker LLM-only) | Filed | #34 | | **#18** | OpenRPC-driven Python code generation | Open | #27 (OpenRPC on all services), #36 (aibroker role clarified) | ### Phase 4: Polish | Issue | Title | Status | Dependencies | |-------|-------|--------|--------------| | **#33** | Compute island: TFGrid connect | Open | — | | — | Intent-based routing in aibroker | Future | #18, #36 | ## Design Principles 1. **OpenRPC = single source of truth** — MCP tools, Python clients, SDKs, docs, discovery all derived from it. Same philosophy as OSIS generating from OTML schemas. 2. **Right tool for the job** — Small models for simple operations (fast, cheap), big models for complex reasoning (accurate, expensive). Aibroker routes intelligently. 3. **Standard patterns everywhere** — Every service uses HeroRpcServer, every service gets MCP, every service gets a Python client. No special cases. 4. **Context-scoped by default** — User's active workspace (Geomind, Default, etc.) flows through to every tool call. ## Key Repos | Repo | Role | |------|------| | hero_rpc (`hero_service` crate) | Server framework: HeroRpcServer, HeroUiServer, lifecycle | | hero_aibroker | Intelligent LLM routing + Python code generation | | hero_shrimp | AI agent + MCP tool management | | hero_inspector | Service discovery, docs, MCP gateway | | hero_services | Deployment orchestration, bridge scripts |
mik-tf commented 2026-03-18 19:42:53 +00:00
Author
Owner
Copy link

Addition: Replace hero_shrimp (Bun/TypeScript) with Rust-native hero_agent

Problem

hero_shrimp is the only non-Rust component in the entire Hero ecosystem. This creates constant friction: different build toolchain, compiled Bun binary quirks, stdio pipe issues with bridge scripts, no debug output in containers. The current MCP bridge integration is blocked by a Bun-specific stdio pipe issue.

Proposal

Add to Phase 3 (after #27 HeroRpcServer + #18 code generation):

hero_agent — Rust-native AI agent replacing hero_shrimp:

  • Uses HeroRpcServer pattern (same as every other service)
  • Talks to services via Unix socket HTTP directly (no bridge scripts)
  • LLM client calls aibroker via HTTP (trivial in Rust)
  • Agent loop: match on tool results (Rust is ideal for this)
  • Conversation state: SQLite (rusqlite)
  • Admin dashboard: Axum web server (same pattern as hero_auth, hero_inspector)
  • MCP: native Rust, already proven in 6 services

Updated Phase 3

Issue Title Dependencies
#36 Clean MCP architecture #34
#18 OpenRPC-driven code generation #27, #36
NEW hero_agent: Rust-native AI agent #27, #18

Short term

Fix the immediate shrimp issue (direct HTTP instead of bridge scripts) so #34 can close. The Rust rewrite happens after the foundation (#27, #18) is in place.

## Addition: Replace hero_shrimp (Bun/TypeScript) with Rust-native hero_agent ### Problem hero_shrimp is the only non-Rust component in the entire Hero ecosystem. This creates constant friction: different build toolchain, compiled Bun binary quirks, stdio pipe issues with bridge scripts, no debug output in containers. The current MCP bridge integration is blocked by a Bun-specific stdio pipe issue. ### Proposal Add to Phase 3 (after #27 HeroRpcServer + #18 code generation): **hero_agent** — Rust-native AI agent replacing hero_shrimp: - Uses `HeroRpcServer` pattern (same as every other service) - Talks to services via Unix socket HTTP directly (no bridge scripts) - LLM client calls aibroker via HTTP (trivial in Rust) - Agent loop: match on tool results (Rust is ideal for this) - Conversation state: SQLite (rusqlite) - Admin dashboard: Axum web server (same pattern as hero_auth, hero_inspector) - MCP: native Rust, already proven in 6 services ### Updated Phase 3 | Issue | Title | Dependencies | |-------|-------|--------------| | #36 | Clean MCP architecture | #34 | | #18 | OpenRPC-driven code generation | #27, #36 | | NEW | hero_agent: Rust-native AI agent | #27, #18 | ### Short term Fix the immediate shrimp issue (direct HTTP instead of bridge scripts) so #34 can close. The Rust rewrite happens after the foundation (#27, #18) is in place.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
development_home27
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#38
No description provided.