lhumina_code/hero_router

Fork 0

Hero service agent improvements #34

New issue

Open

opened 2026-04-12 09:00:46 +00:00 by timur · 3 comments

timur commented

2026-04-12 09:00:46 +00:00

Owner

The hero service agent is an agent that is able to create generate python scripts to work against hero services. When we ask it a prompt it first:

uses a model that recognizes intent and given a set of descriptions of services available and chooses which services will be necessary for the given task, it's prompted with initial prompt, some instructions, and all available service descriptions
then a second prompt is provided to a model with the python client interface stubs of relevant request and initial intent, and provided instructions to generate python code using the python clients
then this python code is executed to code against the services, and if an error is returned from the python code, a third model is used to debugs and fix the python script from the error msg.

This uses hero_proc to execute the python, and model calls over hero_aibroker.

We want a few improvements:

we want settings which allows us to configure the models we use etc.
we want to be able to see clear logs and tokens used etc.

Thinking about this, actually: This entire workflow is hardcoded, but this sort of defining control flows of harnesses and wanting to configure models used and see logs per steps and rerun etc and set executors per step (like is it a ai call for a model over ai broker or a python script to be executed.) So we want a separate hero service for creating control flow graphs, lets call it hero logic, where we can define workflows and nodes and templates for workflows and nodes etc. should be built for nodes being capable of executing ai calls or script execution etc. the node execution should be handled by hero_proc, as hero_proc provides infrastructure to execute actions in a way and see logs etc, its the action executer, and we want to make use of that, so there can be links to the hero_proc actions for nodes executed etc. Lets call this hero_logic. It should be a hero service developed in accordance with best practices defined in claude skills in hero_skills. It should be a hero rpc server that uses osis as backend for control flow graph data structures, perhaps either importing and enhancing existing models from hero_rpc or creating new ones for hero_logic. see and understand how hero rpc services with osis support can be easily created in https://forge.ourworld.tf/lhumina_code/hero_rpc

Then, essentially, the way the agent works and produces high level output and logs will remain in hero_router, but the service and overall agent views will provide links to the hero_logic ui to see the plays of that control flow, step by step logs, output like tokens used for ai calls, errors for py exection etc. so then hero_router is the user friendly way to use these flows to code against hero services but it uses hero_logic behind the scenes.

The hero service agent is an agent that is able to create generate python scripts to work against hero services. When we ask it a prompt it first: 1. uses a model that recognizes intent and given a set of descriptions of services available and chooses which services will be necessary for the given task, it's prompted with initial prompt, some instructions, and all available service descriptions 2. then a second prompt is provided to a model with the python client interface stubs of relevant request and initial intent, and provided instructions to generate python code using the python clients 3. then this python code is executed to code against the services, and if an error is returned from the python code, a third model is used to debugs and fix the python script from the error msg. This uses [hero_proc](https://forge.ourworld.tf/lhumina_code/hero_proc) to execute the python, and model calls over [hero_aibroker](https://forge.ourworld.tf/lhumina_code/hero_aibroker). We want a few improvements: - we want settings which allows us to configure the models we use etc. - we want to be able to see clear logs and tokens used etc. Thinking about this, actually: This entire workflow is hardcoded, but this sort of defining control flows of harnesses and wanting to configure models used and see logs per steps and rerun etc and set executors per step (like is it a ai call for a model over ai broker or a python script to be executed.) So we want a separate hero service for creating control flow graphs, lets call it hero logic, where we can define workflows and nodes and templates for workflows and nodes etc. should be built for nodes being capable of executing ai calls or script execution etc. the node execution should be handled by hero_proc, as hero_proc provides infrastructure to execute actions in a way and see logs etc, its the action executer, and we want to make use of that, so there can be links to the hero_proc actions for nodes executed etc. Lets call this hero_logic. It should be a hero service developed in accordance with best practices defined in claude skills in [hero_skills](https://forge.ourworld.tf/lhumina_code/hero_skills). It should be a hero rpc server that uses osis as backend for control flow graph data structures, perhaps either importing and enhancing existing models from hero_rpc or creating new ones for hero_logic. see and understand how hero rpc services with osis support can be easily created in https://forge.ourworld.tf/lhumina_code/hero_rpc Then, essentially, the way the agent works and produces high level output and logs will remain in hero_router, but the service and overall agent views will provide links to the hero_logic ui to see the plays of that control flow, step by step logs, output like tokens used for ai calls, errors for py exection etc. so then hero_router is the user friendly way to use these flows to code against hero services but it uses hero_logic behind the scenes.

timur referenced this issue from lhumina_code/hero_logic

2026-04-12 09:24:50 +00:00

Implement hero_logic: General-Purpose DAG Control Flow Engine #1

timur commented

2026-04-12 09:25:57 +00:00

Author

Owner

Understanding & Plan

After studying the current agent implementation in hero_router (agent.rs, python_codegen.rs, routes), the hero_proc architecture (actions, jobs, runs), and the hero_rpc/OSIS framework, here's the summary:

Current Problem

The agent pipeline in hero_router is a hardcoded 3-step flow (service selection → code generation → script execution + retry). There's no way to:

Configure models per step
See per-step logs, timing, or token usage
Reuse the control flow pattern for other workflows
Inspect or replay individual steps

Solution: `hero_logic`

A new hero RPC service implementing a general-purpose DAG control flow engine:

Workflows — DAGs of typed nodes (AI calls, script execution, conditionals, transforms) with directed edges carrying data mappings
Templates — stored in a templates/ directory in the repo; examples show templates configured with real service specs
Plays — execution instances of workflows with per-node status, logs, timing, and token metrics
All node execution via hero_proc — every node (including AI calls) creates a hero_proc action/job, providing uniform logging, process management, and observability
Full OSIS persistence — Workflow and Play are root objects with SmartID, full-text search, and generated CRUD

How hero_router changes

Agent request arrives at hero_router
hero_router instantiates the service_agent template via hero_logic API with model config, service catalog, etc.
hero_logic executes the DAG, delegating each node to hero_proc
hero_router returns the result with a play_sid linking to hero_logic UI for detailed step-by-step inspection
hero_router remains the user-friendly agent interface; hero_logic is the execution engine

Full Spec Issue

Detailed specification (data models, OSchema definitions, RPC API, crate structure, DAG engine design, UI requirements, integration patterns, and phased implementation plan) has been created:

→ hero_logic#1 — Implement hero_logic: General-Purpose DAG Control Flow Engine

## Understanding & Plan After studying the current agent implementation in `hero_router` (`agent.rs`, `python_codegen.rs`, routes), the `hero_proc` architecture (actions, jobs, runs), and the `hero_rpc`/OSIS framework, here's the summary: ### Current Problem The agent pipeline in hero_router is a hardcoded 3-step flow (service selection → code generation → script execution + retry). There's no way to: - Configure models per step - See per-step logs, timing, or token usage - Reuse the control flow pattern for other workflows - Inspect or replay individual steps ### Solution: `hero_logic` A new hero RPC service implementing a **general-purpose DAG control flow engine**: - **Workflows** — DAGs of typed nodes (AI calls, script execution, conditionals, transforms) with directed edges carrying data mappings - **Templates** — stored in a `templates/` directory in the repo; examples show templates configured with real service specs - **Plays** — execution instances of workflows with per-node status, logs, timing, and token metrics - **All node execution via hero_proc** — every node (including AI calls) creates a hero_proc action/job, providing uniform logging, process management, and observability - **Full OSIS persistence** — Workflow and Play are root objects with SmartID, full-text search, and generated CRUD ### How hero_router changes 1. Agent request arrives at hero_router 2. hero_router instantiates the `service_agent` template via hero_logic API with model config, service catalog, etc. 3. hero_logic executes the DAG, delegating each node to hero_proc 4. hero_router returns the result with a `play_sid` linking to hero_logic UI for detailed step-by-step inspection 5. hero_router remains the user-friendly agent interface; hero_logic is the execution engine ### Full Spec Issue Detailed specification (data models, OSchema definitions, RPC API, crate structure, DAG engine design, UI requirements, integration patterns, and phased implementation plan) has been created: **→ [hero_logic#1 — Implement hero_logic: General-Purpose DAG Control Flow Engine](https://forge.ourworld.tf/lhumina_code/hero_logic/issues/1)**

timur referenced this issue from a commit

2026-04-12 11:11:03 +00:00

feat: integrate hero_logic for DAG-based agent execution

timur commented

2026-04-12 11:11:20 +00:00

Author

Owner

Phase 3 Complete: hero_router ↔ hero_logic Integration

hero_logic fixes (b7cb162)

build_node_input() now merges workflow input as global variables into every node's input (not just start nodes). Template variables like {{prompt}} and {{service_interface}} are available to all nodes in the DAG.
Script execution now supports scripts_dir in input data — prepends sys.path.insert() so Python scripts can find staged client libraries.
New template: single_service_agent.json — 4-node DAG (code_generation → script_execution → error_debug/result_summary) for per-service agents.

hero_router integration (`68c8a14`)

Added logic_socket_path(), call_logic_rpc(), wait_for_play() RPC helpers
Added run_agent_via_logic() — single-service agent delegation to hero_logic
Added run_global_agent_via_logic() — multi-service agent delegation to hero_logic
Modified run_agent() and run_global_agent() to try hero_logic first, with graceful fallback to the existing inline pipeline when hero_logic isn't running

How it works

hero_router detects hero_logic socket at $HERO_SOCKET_DIR/hero-logic/rpc.sock
Prepares context (service catalog, interfaces, staged Python clients) — same as before
Calls logicservice.workflow_from_template() + logicservice.play_start() via JSON-RPC
Polls logicservice.play_status() until completion
Extracts result and maps back to the existing AgentResponse/GlobalAgentResponse format

No breaking changes — existing agent API is 100% backwards compatible. hero_logic integration is optional and transparent.

## Phase 3 Complete: hero_router ↔ hero_logic Integration ### hero_logic fixes (b7cb162) - **`build_node_input()`** now merges workflow input as global variables into every node's input (not just start nodes). Template variables like `{{prompt}}` and `{{service_interface}}` are available to all nodes in the DAG. - **Script execution** now supports `scripts_dir` in input data — prepends `sys.path.insert()` so Python scripts can find staged client libraries. - **New template**: `single_service_agent.json` — 4-node DAG (code_generation → script_execution → error_debug/result_summary) for per-service agents. ### hero_router integration (68c8a14) - Added `logic_socket_path()`, `call_logic_rpc()`, `wait_for_play()` RPC helpers - Added `run_agent_via_logic()` — single-service agent delegation to hero_logic - Added `run_global_agent_via_logic()` — multi-service agent delegation to hero_logic - Modified `run_agent()` and `run_global_agent()` to **try hero_logic first**, with graceful fallback to the existing inline pipeline when hero_logic isn't running ### How it works 1. hero_router detects hero_logic socket at `$HERO_SOCKET_DIR/hero-logic/rpc.sock` 2. Prepares context (service catalog, interfaces, staged Python clients) — same as before 3. Calls `logicservice.workflow_from_template()` + `logicservice.play_start()` via JSON-RPC 4. Polls `logicservice.play_status()` until completion 5. Extracts result and maps back to the existing `AgentResponse`/`GlobalAgentResponse` format No breaking changes — existing agent API is 100% backwards compatible. hero_logic integration is optional and transparent.

timur referenced this issue from a commit

2026-04-12 11:30:19 +00:00

refactor: remove inline agent pipeline, use hero_logic exclusively

timur commented

2026-04-12 13:47:14 +00:00

Author

Owner

Progress Update — hero_logic integration + chat UI

The core work described in this issue has been implemented across two repos:

hero_logic (new service)

DAG execution engine with Workflow, Node, Edge, Play, NodeRun data models
Template system — service_agent template defines the 4-node pipeline: service_selection → code_generation → script_execution → result_summary
OSIS storage for workflows and plays
Node execution via hero_proc for both AI calls (through hero_aibroker) and script execution
Crash resilience — panic catching in tokio::spawn, safe error returns in executor, heredoc-based JSON in bash scripts
Full spec: hero_logic#1

hero_router changes

Unified agent code path — both POST /:service/agent (per-service) and POST /api/agent (global) use the same run_agent() with an optional service filter
Chat-style UI replacing the old form+card interface:
- Conversation history with message bubbles
- Thinking indicator while agent runs
- Collapsible Script and Raw Output sections per response
- Metadata badges (services used, duration, attempts)
- Enter to send, Shift+Enter for newline
Play detail endpoint — GET /api/agent/play/:play_sid proxies to hero_logic for node-by-node inspection
Workflows link in both global and per-service agent UIs linking to hero_logic service page
play_sid included in every agent response for traceability

Still TODO

hero_logic admin UI (dedicated dashboard for browsing/inspecting plays and workflows)
Model configuration settings (persisted preferences for which models to use per node type)
Token usage display in agent chat UI (data is tracked in NodeRun but not yet surfaced)
Per-node retry from UI
hero_proc action links in play detail view

## Progress Update — hero_logic integration + chat UI The core work described in this issue has been implemented across two repos: ### hero_logic (new service) - **DAG execution engine** with Workflow, Node, Edge, Play, NodeRun data models - **Template system** — `service_agent` template defines the 4-node pipeline: service_selection → code_generation → script_execution → result_summary - **OSIS storage** for workflows and plays - **Node execution** via hero_proc for both AI calls (through hero_aibroker) and script execution - **Crash resilience** — panic catching in tokio::spawn, safe error returns in executor, heredoc-based JSON in bash scripts - Full spec: [hero_logic#1](https://forge.ourworld.tf/lhumina_code/hero_logic/issues/1) ### hero_router changes - **Unified agent code path** — both `POST /:service/agent` (per-service) and `POST /api/agent` (global) use the same `run_agent()` with an optional service filter - **Chat-style UI** replacing the old form+card interface: - Conversation history with message bubbles - Thinking indicator while agent runs - Collapsible Script and Raw Output sections per response - Metadata badges (services used, duration, attempts) - Enter to send, Shift+Enter for newline - **Play detail endpoint** — `GET /api/agent/play/:play_sid` proxies to hero_logic for node-by-node inspection - **Workflows link** in both global and per-service agent UIs linking to hero_logic service page - `play_sid` included in every agent response for traceability ### Still TODO - [ ] hero_logic admin UI (dedicated dashboard for browsing/inspecting plays and workflows) - [ ] Model configuration settings (persisted preferences for which models to use per node type) - [ ] Token usage display in agent chat UI (data is tracked in NodeRun but not yet surfaced) - [ ] Per-node retry from UI - [ ] hero_proc action links in play detail view