# ForestHub AI Full Reference > ForestHub is the Edge AI and Agents Orchestration Platform. Workflows are graphs and the LLM is one node among many, inspectable, replayable, auditable, bounded by design. The engine ships as a Go binary in a Docker image and runs on any Linux edge device. Engine and LLM-Proxy ship as public packages with cross-language contracts. The platform runs without our backend, and the managed SaaS adds logging, device health, OTA deploys, and billing as optional convenience. --- ## What is an edge agent? An edge agent is an AI agent that runs where the work happens, on a Linux edge device, not in the cloud. It perceives local signals (sensors, MQTT/Modbus/OPC-UA), reasons over them, and acts on the physical system without a round-trip to a datacenter. ForestHub makes edge agents you can run in production: the workflow is a deterministic graph, the LLM is one node among many, inspectable, replayable, auditable, bounded by design. **Edge agents vs cloud agents.** Where a cloud agent lets the model drive and hope (deciding which tools to call and when to stop, in a datacenter, with behavior that is hard to enumerate ahead of time), an edge agent runs a bounded graph where the LLM is a single, replaceable node and every action is verifiable. It runs next to the sensors and actuators it controls, keeps working offline, and keeps operational data local. That is the only kind of agent you can safely put next to a machine. **Why edge agents must be bounded.** Next to a machine, a wrong decision means a relay actuates or a setpoint changes. An edge agent earns the right to act by being bounded by design: the workflow is a deterministic graph, the LLM is one node among many (replaceable by a rule, classical ML, or a smaller on-device model), every run is replayable and auditable, and the agent cannot actuate anything that was not wired into the graph. Full definition and contrast: https://www.foresthub.ai/en/edge-agents --- ## Company ForestHub GmbH is a German deep-tech startup founded in 2025, headquartered in Villingen-Schwenningen, Baden-Wuerttemberg. Registered at Amtsgericht Freiburg, HRB 734331. Founded by embedded engineers from the Hahn-Schickard Institute, one of Germany's leading research institutes for applied microsystems technology, with backgrounds spanning embedded systems, software architecture, simulation, machine learning, and tech governance. The four founders combine deep technical expertise (PhD-level software architecture, Master's in Simulation Technology from Stuttgart, Mechatronics + Deep Neural Networks research at KIT and Hahn-Schickard) with non-technical domain expertise (political science, business economics, tech governance, AI policy research). The team operates at the intersection of embedded systems, edge computing, and agentic AI, fields that are converging rapidly. --- ## Product Architecture ForestHub consists of three components: ### 1. Agent Builder A visual web application at https://app.foresthub.ai. Builders author a workflow as a graph on a canvas. Nodes in the graph are deterministic operations (read sensor, transform value, branch, actuate, write to database), LLM agents, or control-flow / trigger primitives. Workflows version like code; deploys roll back like deployments. Top-level sidebar: Dashboard, Workflows, Devices, Agents, Networks, Knowledge Bases, Monitoring, Settings. Builder modes: edit / preview / debug. Builder-sidebar tabs: Nodes, Functions, Variables, Agents, Conversations. ### 2. Engine A Go-based graph interpreter delivered as a distroless Docker image (`linux/amd64` + `linux/arm64`, ~10 to 15 MB). The image contains a statically compiled Go binary (`engine` from `cmd/engine`) that loads `workflow.json` at startup and interprets the graph at runtime. Endpoints: `POST /deploy`, `POST /stop`, `GET /healthz`. Default listen port `:8081`. Configured via environment variables (`ENGINE_ID`, `ENGINE_PUBLIC_URL`, `ENGINE_MANIFEST_FILE`, `ENGINE_LOG_LEVEL`, etc.). The engine is **not** a code generator. It does not produce C, C++, or bare-metal output. Builders write workflows, deploy the Docker image to the target device, the image loads the workflow, and the engine executes it. ### 3. Orchestration Layer (managed SaaS, optional) The backend stack handling workflow versioning, device registry, deployment, telemetry, and multi-LLM provider routing. This layer (internally called **`fh-backend`**) is the **managed convenience**: closed-source SaaS adding logging UI, device-online status, OTA deploys, token accounting, agent registry, IoT gateway, and billing on top of the open engine. The platform is functional without it: self-host the engine binary, validate workflows with the CLI, deploy directly to your own Linux edge devices. ### Open-Source Posture The public repository is **`edge-agents`** at [github.com/ForestHubAI/edge-agents](https://github.com/ForestHubAI/edge-agents) (public since 2026-05-19, dual-licensed **AGPL-3.0-only** + commercial license on request to `hello@foresthub.ai`). Structure: - **`contract/`**: Source of truth. Language-neutral OpenAPI 3.0.3 schemas (`workflow.yaml`, `engine.yaml`, `llmproxy.yaml`, `debug.yaml`). Both Go and TypeScript generate types from these, with no API drift. - **`go/`**: Go module `github.com/ForestHubAI/edge-agents/go`. Engine runtime + LLM-proxy. - **`ts/`**: npm workspace: `workflow-core` (headless model) ← `workflow-builder` (React canvas component library) ← `app` (reference SPA + `fh-builder` CLI). The builder is a standalone component with a public API, and embedding consumers use it directly. - **`skills/`**: Claude Code skill wrapping the workflow CLI. CLI: `fh-builder` (commands: `open`, `validate`, `bundle`). Lives in `ts/app/`. Deliberately thin. AI-driven workflow generation is in active development and not yet shipped. The repository runs **standalone and offline, no external services or accounts required** (verbatim from the project README). --- ## Hardware Coverage The engine targets every Linux edge device: - Linux (`amd64` + `arm64`): Yocto, Buildroot, OpenWrt, OpenSTLinux, Balena, standard distributions. - Hardware classes: gateways, NUCs, NVIDIA Jetsons, Raspberry Pis, industrial PCs. Linux covers 95%+ of the edge/IoT market by volume. The four Linux-incompatible RTOSes (QNX, VxWorks, Integrity, LynxOS) target a narrow safety-critical certified-RTOS segment that is distinct from the broader edge/IoT market and not supported. --- ## Workflow Capabilities ### Hardware IO Through Linux kernel APIs (sysfs, chardev, termios): - GPIO (digital input/output, edge detection, debounce) - ADC (analog read via `/sys/bus/iio/`) - DAC (analog write) - PWM (`/sys/class/pwm/`) - Serial / UART (POSIX termios) - I²C, SPI ### Industrial Protocols (first-party node types) - MQTT (Mosquitto + auth plugin): `OnMqttMessage` trigger, `MqttPublish` output - Modbus TCP/RTU - OPC-UA ### LLM Routing: Three Modes per Workflow - **Backend-Key (Hosted)**: FH-managed proxy across OpenAI, Anthropic, Gemini (API-Key or Vertex AI), Mistral. ForestHub bills the customer and pays the provider. - **Bring-Your-Own-Key**: Customer uses their own API key and pays the provider directly via the FH proxy. - **On-Device**: A self-hosted inference endpoint in the customer's network (llama-server, vLLM, Ollama) wired in via the `selfhosted` provider. Default for ForestHub Edge / on-prem deployments. Different providers per node in the same graph. ### Knowledge Bases (RAG) Domain-specific context as a node type. Customers upload datasheets, specs, service documentation; agents query them at runtime via the `Retriever` node. Backend uses Postgres + pgvector. ### Triggers `OnStartup`, `Ticker`, `Alarm`, `Delay`, `OnPinEdge`, `OnThreshold`, `OnSerialReceive`, `OnMqttMessage`, `OnFunctionCall`. Sensor events, MQTT messages, schedules, webhooks, and state-variable changes are all nodes in the same graph. ### Node Catalogue (canonical names) Input: `ReadPin`, `SerialRead`, `Retriever` · Output: `WritePin`, `SerialWrite`, `MqttPublish` · Logic: `If` · Data: `SetVariable` · AI: `Agent` (UI label "LLM Agent"), `WebSearchTool` · Function: `FunctionCall` · Triggers (above). --- ## Deployment Paths Three options: 1. **API push**: `POST /deploy` from the builder to the registered engine endpoint with the workflow JSON in the body. 2. **Direct-IP within your LAN**: the engine self-registers and exposes itself at `ENGINE_PUBLIC_URL`, and the builder pushes directly. 3. **Bootstrap-bundle download**: a tarball (`agent--bootstrap.tar.gz`) containing `docker-compose.yml`, `manifest.json`, and `README.md`. Customer copies the tarball to the target device, runs `docker compose up`, and the workflow is live. Suitable for offline / air-gapped install. Per-device deploy history with rollback. Hot-reload of graphs without restarting the engine container. --- ## The Lead Argument: Graph-first vs Loop-first Every popular agent framework today (LangChain, OpenAI Agents SDK, Claude Code, n8n in its AI modes) shares one design choice: the LLM's loop is the program. You give the LLM a system prompt, a pile of tools, and let it iterate until it decides it's done. Skills, hooks, sub-turns, steering, MCP plug-ins are bolted onto that loop. For a personal assistant, that's the right model. For industrial control, it's the wrong one. When the consequence of a tool call is a relay actuating, a setpoint changing, or a dose being delivered, "whatever the LLM decided" is not an acceptable answer to your auditor. Industrial customers need workflows that are: - **inspectable**: every possible LLM decision is a visible wire on the canvas - **replayable**: the same inputs reproduce the same flow - **auditable**: the set of actions is finite and enumerable - **bounded**: the LLM cannot reach data or systems it wasn't explicitly granted access to Loop-first frameworks structurally cannot deliver these properties. You can sandbox them, denylist their shells, bolt on approval hooks, but the underlying model stays "give the LLM the keys and trust the runtime to constrain it." ForestHub inverts the relationship: the graph is the program; the LLM is a node. Some nodes are deterministic, others are LLM agents. The engine orchestrates everything; the LLM is one component type among many. A loop-first agent (one big prompt, many tools, run-to-completion) is available as a single agent node inside the graph. Constraint is opt-in. The graph is a strict superset of loop-first frameworks. --- ## Six Graph-First Patterns (Documented in detail at https://www.foresthub.ai/en/patterns) 1. **Verification-gated Actuation** (Safety): LLM proposes, deterministic verifier disposes. The actuator is unreachable from the LLM node and can only fire via the verifier. 2. **LLM-as-Classifier-Only** (Safest LLM use): The LLM only classifies into a finite branch set, and all action logic is deterministic. The safest possible LLM use in a control loop. 3. **Replay Testing** (Engineering): Every LLM call is a node with structured I/O. Record production runs, replay in CI with the LLM mocked. Practically impossible in loop-first frameworks. 4. **Confidence-routed Model Cascade** (Cost): Haiku classifies, on low confidence Sonnet takes over, on very low confidence Opus or human. ~10× cost reduction without tail-quality loss. 5. **Shadow-Mode Deployment** (Operations): New agent runs in parallel with existing logic, and output goes to a log instead of the actuator. After N days of comparison, flip one wire. 6. **State-Machine-augmented Agent** (Graph-native): Most transitions are deterministic FSM, and the LLM is invoked only for ambiguous transitions. FSM and LLM share one runtime. --- ## Compliance Compliance is an architecture property, not a separate feature. - **GDPR / DSGVO**: All processing on the customer's hardware unless wired otherwise. No telemetry to a vendor cloud unless the builder explicitly wires it. - **EU AI Act**: Visual auditability of LLM decisions is a graph property. Every run is a structured event log, and CI replay is a primitive. Risk classification, documentation, and human-in-the-loop controls are workflow patterns. - **Cyber Resilience Act (CRA) Readiness**: Cosign-signed engine images, SBOM generation per build, Trivy gate in the release pipeline. Multi-arch CI on tag-push. - **Open-Core**: Auditable, transparent core. Inspectable workflows + readable artifacts + signed images. --- ## Use Cases (Documented at https://www.foresthub.ai/en/solutions) - **Intelligent Service Technician**: On-device fault diagnosis for industrial equipment. Sensor analysis, anomaly detection, guided troubleshooting, all on-device. - **Building Automation**: Local AI for HVAC, lighting, energy management on a Linux edge gateway in the building. - **Predictive Maintenance**: Vibration / temperature analysis, anomaly detection, alerts before failures. - **Autonomous Sensing**: Threshold-gated triggers and lightweight inference at small Linux gateways close to the sensor field, and only significant events transmit upstream. --- ## Pricing The open source runtime (engine, LLM-proxy, workflow contract and visual builder) is free under AGPL-3.0 and can be self-hosted at no cost. The managed platform is free to start with no credit card. A commercial license (for use cases that need a non-AGPL track) and OEM engineering services are scoped and priced per project. Workflows are portable artifacts the customer owns. See https://www.foresthub.ai/en/pricing for the model and https://app.foresthub.ai for the managed platform. --- ## Open Source **`edge-agents`**: The ForestHub workflow platform. Public repository: [github.com/ForestHubAI/edge-agents](https://github.com/ForestHubAI/edge-agents). Contains the Go engine + LLM-proxy (`go/`), the language-neutral OpenAPI 3.0.3 contract (`contract/`), the TypeScript workspace with visual builder + `fh-builder` CLI (`ts/`), and a Claude Code skill (`skills/`). Runs standalone and offline. **Dual-licensed**: AGPL-3.0-only for the public release (with the AGPL's network-copyleft obligation). A commercial license is available for use cases incompatible with AGPL, contact `hello@foresthub.ai`. The closed-source `fh-backend` (governance, hosting, multi-tenant control plane) consumes this repo and is not part of the public release. **boardsmith**: A separate open-source CLI tool that turns text prompts into KiCad schematics, BOM, and firmware. Works offline, AGPL-3.0. Repository: https://github.com/ForestHubAI/boardsmith --- ## Reference Surfaces ### Glossary 50 edge AI and agent terms in five categories (foundations, models, agents, safety, industrial). Each term has a vendor-neutral, answer-first definition and a permalink anchor, published as a single DefinedTermSet: https://www.foresthub.ai/en/glossary ### Comparisons Sourced comparisons with adjacent tools. Every competitor fact maps to a cited source and carries a quarterly verification date shown on the page: - Hub: https://www.foresthub.ai/en/compare - ForestHub vs n8n (general-purpose workflow automation): https://www.foresthub.ai/en/compare/foresthub-vs-n8n - ForestHub vs Node-RED (classic IoT flow tool): https://www.foresthub.ai/en/compare/foresthub-vs-node-red - ForestHub vs Litmus Edge (industrial DataOps platform): https://www.foresthub.ai/en/compare/foresthub-vs-litmus - ForestHub vs LiteRT-LM (on-device inference runtime): https://www.foresthub.ai/en/compare/foresthub-vs-litert-lm ### Changelog Curated chronological stream of user-visible platform updates, sourced from public edge-agents releases: https://www.foresthub.ai/en/changelog (RSS: https://www.foresthub.ai/en/changelog/rss.xml) ### Guides In-depth guides on the resources hub: - What is Edge AI Orchestration: https://www.foresthub.ai/resources/guides/what-is-edge-ai-orchestration - Edge Agents vs Cloud Agents: https://www.foresthub.ai/resources/guides/edge-agents-vs-cloud-agents - How to Build Agentic Edge AI: https://www.foresthub.ai/resources/guides/how-to-build-agentic-edge-ai - Edge AI Agents on Microcontrollers: https://www.foresthub.ai/resources/guides/edge-ai-agents-on-microcontrollers --- ## Contact - **Website**: https://www.foresthub.ai - **Platform**: https://app.foresthub.ai - **Email**: hello@foresthub.ai - **LinkedIn**: https://www.linkedin.com/company/foresthub-ai/ - **GitHub**: https://github.com/ForestHubAI - **Location**: Villingen-Schwenningen, Baden-Wuerttemberg, Germany