Hector Agent Runtime
A self-hosted Go runtime for configuring, running, and operating A2A-compatible AI agents from YAML or Studio.
- Source repo
- verikod/hector
- Stars
- ★ 60
- Last updated
- 4mo ago
- License
- MIT
- Primary language
- Go
- FA score
- 55/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformOpenAI API · Claude API
- You'll need
- Typical use
- A platform team needs to run an agent service on-premise, in an air-gapped network, or in its own cloud with a single binary and locally controlled credentials.
- Main limitation
- Using cloud models from Anthropic, OpenAI, or Gemini requires the corresponding provider API keys; Ollama is the documented local alternative.
- Source review
- 55/100 · Major gaps
What does this agent do, and when should you use it?
Hector is an open-source AI agent runtime written in Go for self-hosted deployments. Its release binary embeds Hector Studio, a web UI served at the root path when hector serve runs. The runtime supports llm, sequential, parallel, loop, conditional, and remote agent types, using A2A for agent interoperability and MCP for tool connectivity. It persists sessions, tasks, and checkpoints in SQLite or PostgreSQL for recovery and queue handling. Teams can manage multi-tenant applications, authentication, triggers, RAG, guardrails, and notifications through YAML and the Admin API.
When started with hector serve, Hector serves Studio, the Admin API, and the agent runtime. It consumes YAML configuration or application configuration managed through /admin/apps, then executes llm, sequential, parallel, loop, conditional, or remote agents; LLM settings can target Anthropic, OpenAI, Gemini, or Ollama. Agents can call MCP tools over stdio or SSE, plus filetool, webtool, commandtool, memorytool, searchtool, todotool, approvaltool, and agenttool. Runtime events, tasks, checkpoints, and application configuration are persisted in SQLite or PostgreSQL; failed tasks can retry and be inspected or requeued through /admin/queue/dlq. It can also initiate or report work through cron triggers, webhooks, and A2A-compliant push notifications.
- A platform team needs to run an agent service on-premise, in an air-gapped network, or in its own cloud with a single binary and locally controlled credentials.
- A support platform needs to create isolated customer applications through the Admin API, with separate agent configuration, session storage, vector collections, and JWTs.
- An engineering team needs to expose existing MCP stdio or SSE services to agents while filtering the tools made available.
- An operations team needs daily reports on a cron schedule or needs to turn GitHub webhook payloads into agent inputs.
- A team running long-lived work needs SQL-backed retries, exponential backoff, checkpoints, recovery, and dead-letter-queue requeueing.
How do you install or deploy this agent?
On macOS or Linux, run: curl -fsSL https://gohector.dev/install.sh | sh, then: hector serve. Alternatives documented are Homebrew: brew install verikod/tap/hector followed by hector serve; or Docker: docker run -p 8080:8080 ghcr.io/verikod/hector:latest serve. On first launch, open http://localhost:8080/ and enter the admin secret printed in the terminal; Studio can then configure LLM providers, create agents, and start chatting. Cloud providers such as Anthropic and OpenAI need their respective API keys in configuration, for example ${ANTHROPIC_API_KEY} or ${OPENAI_API_KEY}. To build from source, run go build -o hector ./cmd/hector; the README specifies Go 1.24+.
How do you use this agent?
Start hector serve, enter the terminal-provided admin secret in Studio, configure an LLM provider, and create an agent; Studio includes streaming chat and a tool-call trace. Alternatively, define agents, tools, llms, guardrails, and document_stores in YAML, then run ./hector serve --config config.yaml. To enable the management interface, run hector serve --auth-secret "admin-secret" and POST to /admin/apps to create an application; the response includes an application JWT. Validate a deployment configuration with hector validate --config production.yaml before deployment.
What are this agent's strengths and limitations?
- The release build embeds Studio in a single Go binary described as roughly 30MB, with documented Linux, macOS, and Windows operation.
- It combines A2A-based agent interoperability with MCP tool connectivity, including both stdio and SSE transports.
- Sessions, tasks, and checkpoints persist in SQLite or PostgreSQL, with retries, exponential backoff, recovery, and dead-letter queue endpoints.
- Multi-tenant applications are managed through the Admin API with per-application JWTs, isolated state storage, and separate vector-store collections.
- Using cloud models from Anthropic, OpenAI, or Gemini requires the corresponding provider API keys; Ollama is the documented local alternative.
- A PostgreSQL deployment requires the operator to provide and operate PostgreSQL; SQLite is the documented default database.
- Building from source requires Go 1.24+; building a release binary with embedded Studio or running the Studio development server also requires Node.js.
- The supplied material does not document high-availability topology, backup procedures, resource sizing, or performance differences among vector stores and model providers.
How does this agent compare with similar options?
Provider selection is configuration-level: the examples list Anthropic, OpenAI, Gemini, and Ollama. Vector-store choices are chromem (the default), Qdrant, Pinecone, Weaviate, and Milvus; the supplied material does not establish performance or cost differences between them.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| Hector Agent Runtime This agent | 55 · Major gaps | ★ 60 | 4mo ago | Go | OpenAI API · Claude API |
| AGNT Agent OS | 52 · Major gaps | ★ 543 | 4d ago | JavaScript | Codex · Claude Code · OpenAI API · Claude API |
| CompozyOS | 52 · Major gaps | ★ 2.8k | 3d ago | Go | ChatGPT · Codex · Claude Code |
| FIM One Enterprise AI Agent Platform | 48 · Major gaps | ★ 1.5k | 7d ago | Python | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: README claims support for tool sandboxing, command allowlists, approval tools, PII redaction, rate limiting, tenant isolation, but these are assertions without implementation details or test evidence. Deductions: dependency security only lists versions without vulnerability scanning or audit evidence; data flow transparency only describes features without showing actual logging or audit mechanisms; rollback only mentions checkpoints without recovery process; source attribution relies on README badges without verifiable release signatures or supply chain evidence.
Evidence shows: README describes SQL persistence, task queue, retry, dead-letter queue, indicating reliability considerations; CI config includes test, lint, build steps. Deductions: failure messages only mention retry and DLQ without specific error handling or user-visible error examples; dependency availability only lists dependencies without version pinning or mirroring strategy.
Evidence shows: README clearly targets teams needing control over AI infrastructure, provides multiple deployment options (on-prem, air-gapped, cloud), supports multiple LLM providers and vector stores, shows various triggers and integration scenarios. Deductions: capability boundaries only illustrated via config examples without full permission model or limitation notes; environment fit lacks detailed system requirements or compatibility matrix.
Evidence shows: README is well-structured with quick start, architecture, API, config reference; provides install scripts, Docker, Homebrew; multiple example configs; MIT license clear. Deductions: naming stability lacks version history or API stability promise; known limitations not explicitly listed; versioning changelog absent; maintenance responsibility only implied via GitHub Actions without explicit statement.
Evidence shows: README claims visual Studio, config-driven, multi-tenant, RAG, guardrails; output is actionable YAML configs and APIs; marginal value in self-hosting and zero dependencies. Deductions: cost-benefit lacks performance benchmarks or resource consumption data; output usability lacks actual output examples or validation.
Evidence shows: README feature claims lack code references or test evidence; CI config includes test steps but no test results or coverage data. Deductions: claim traceability insufficient, features not linked to specific code or tests; cross-source corroboration relies only on README and CI config without independent verification; fact-inference separation not clearly distinguished.
- All security features are asserted without implementation or test evidence; audit before deployment.
- Many dependencies without vulnerability scanning; use dependency scanning tools.
- No changelog provided; be cautious when upgrading.
- Publisher identity unverified; assess supply chain risks yourself.