Skip to content
BranchesTags

Repository files navigation

VibeBot

An experimental multi-agent runtime that I built through VibeCoding.

VibeBot is an agent-system practice project that I started around February 2026. It began as a way for me to learn multi-agent orchestration, prompt engineering, context engineering, and self-iterating AI tools. After the 0.1 and 0.2 explorations, it gradually evolved into the current 0.3 codebase.

This README is not product landing-page copy, and it is not written from VibeBot's own point of view. It is closer to a technical self-narrative from me as a developer, product manager, and agent-system learner: why I split agents into layers, why I use files as the source of truth for assets, why I prefer deterministic routing, and why Provider, Prompt, Memory, Knowledge, Skill, Tool, and Security belong in the same runtime design discussion.

VibeBot is built on Eino, the open-source agent framework from ByteDance. The project was developed mostly through VibeCoding: first forming product and architecture hypotheses, then landing them quickly with AI coding tools, and then using real code, runtime paths, tests, and review to correct the design. I used Trae in the early phase and Qoder later.

Chinese version: README.zh-CN.md

Open-Source Boundary

For now, I plan to open source the code part of VibeBot.

Historical specs, design documents, and phase-by-phase thinking notes will not be published with this repository yet. Some of those documents already lag behind the implementation, and many of them are still process materials that need cleanup. I may publish them later in a separate repository if it becomes useful.

This README follows one rule: public claims should be grounded in the current codebase. Historical documents are internal background for how the design evolved, not required public context for readers.

The current development focus is the VibeBot daemon and WebUI. The CLI entry point still exists in the codebase, but it is paused for now and is not the main usage path highlighted here.

Why I Built VibeBot

The goal of VibeBot is not to clone an existing agent product. It is my engineering practice around a set of lower-level questions:

  • When multiple upstream LLM providers coexist, how should an agent choose models instead of relying entirely on static configuration?
  • As context windows grow, does prompt structure still matter? If yes, how should context be organized and trimmed?
  • Does a multi-agent system need an LLM to route every task? Which decisions should be deterministic?
  • How should access-layer agents, logic-layer agents, and execution-layer agents be separated?
  • Where are the boundaries between Tool, Skill, Memory, Knowledge, and Workflow?
  • Can an agent turn runtime experience into reusable assets that enter a governed lifecycle?
  • Should Security be an external audit layer, or part of the agent runtime itself?
  • For a personal desktop agent, what level of architecture complexity is actually useful?

VibeBot is an engineering exercise for these questions. It is not a paper implementation and not a pure demo. It is a system where I use real code to keep calibrating product judgment.

My current view of self-iterating agents can be compressed into three questions:

  • What am I missing: can the system identify gaps between current capabilities and task requirements?
  • How do I fill the gap: can the system create or distill new Tools, Skills, or Knowledge?
  • Did the fix work: can the system evaluate new assets through execution feedback, usage count, failure rate, and score?

Current Status

The current codebase can be treated as VibeBot 0.3.

It already contains a relatively complete backend runtime, daemon process, gRPC API, WebUI, provider system, agent orchestration, context assembly, Memory/Knowledge, Skill Framework, Workflow, dynamic tools, and ALP asset lifecycle infrastructure.

It is still an experimental project:

  • It is not a stable product for general users.
  • The CLI exists, but the current main path is daemon + WebUI.
  • Some self-iteration capabilities have infrastructure in place, but this should not be read as a fully autonomous self-evolving system.
  • Architecture descriptions in this README are based on the current codebase, not on unpublished spec documents.

To avoid presenting experimental work as a finished product, I describe the current maturity level explicitly:

Area Status Notes
daemon Runtime Main path Core process for Agent Runtime, Memory, Provider, gRPC API, and WebUI gateway
WebUI Main path, evolving One of the current primary entry points; reuses daemon gRPC services through an HTTP gateway
CLI Paused Code remains, but it is not the main README usage path for now
Provider Layer Implemented supplier-aware config, model groups, dynamic catalog, capability resolution, local fallback
Agent Layering Implemented Access / Logic / Execution layering is part of the main runtime path
Debate System Implemented, experimental enhancement Oracle, Morpheus, Trinity, Neo, Synthesizer, and safety veto are present
Cornell Context Assembly Implemented dynamic slots, waterfall trim, user-input protection, cache-safe order
Skill Framework v2 Infrastructure implemented SKILL.md assets, metadata, activation policy, scorecard, and Eino middleware
Dynamic Tool Experimental generation, validation, registration, risk assessment, promote / deprecate; should be enabled carefully
Memory / Knowledge Implemented, evolving local SQLite, FTS, embedding, knowledge store, and graph retrieval paths exist
ALP Core protocol implemented core state machine covers Discover / Create / Evaluate / Iterate; downgrade, deprecation, and cascade repair are handled by concrete asset subsystems
Security Integrated PromptGuard, OutputSanitizer, RequestClassifier, AgentPolicyGuard, and related components are in critical paths

One versioning note: 0.3 refers to the current codebase stage, not a formal release. Terms like v2 and v3 in historical docs or code comments often refer to internal architecture generations, such as Skill Framework v2 or the VibeBot v3 daemon, not public release versions.

Core Design Highlights

1. Provider-Aware Multi-Upstream LLM System

VibeBot's Provider layer is not just "set an API key and choose a model".

I designed it as a multi-upstream, multi-supplier, multi-model-group LLM management layer. It supports:

  • Multiple upstream LLM providers.
  • Supplier-specific handling under the same protocol.
  • Preferred model and preferred group mechanisms, so different tasks can lean toward different model groups.
  • Model capability modeling, including vision, function calling, reasoning, thinking, prompt caching, audio/video input, context window, and more.
  • Model selection based on task capability requirements.
  • Runtime capability learning and capability cache.
  • Health status, circuit breaking, rate limits, concurrency control, budget tracking, and adaptive timeout.

One detail I consider important: the Provider layer includes LiteLLM and OpenRouter model data sources, plus a built-in baseline catalog. At runtime, VibeBot attempts to load model catalogs from LiteLLM / OpenRouter, validates them, and uses them in the dynamic catalog. If network access or the data source fails, it falls back to local cache and built-in data.

This means VibeBot does not depend entirely on a manually maintained model table that quickly goes stale, while still being able to start when external catalog sources are unavailable. For a fast-changing LLM ecosystem, this dynamic catalog plus local fallback is closer to real usage needs than static config alone.

Key implementation:

2. Three-Layer Agent Architecture: Access / Logic / Execution

I did not design VibeBot as one universal agent. I split agent orchestration into three layers:

User / Channel
     |
     v
Access Layer
  - Matrix
  - HybridEvaluator
  - deterministic routing
  - per-binding persona / channel context
     |
     v
Logic Layer
  - DebateOrchestrator
  - Oracle pre-debate analysis
  - LongRange runner
  - Workflow / Plan-Execute
     |
     v
Execution Layer
  - tool-using agents
  - skills
  - MCP / browser / dynamic tools

The Access layer handles entry, classification, fast response, and routing. The Logic layer handles complex reasoning, debate, planning, and long-range tasks. The Execution layer focuses on tool calls and task execution.

This split matters because it avoids two common problems: putting channel adaptation, persona expression, complex reasoning, and tool execution into a single agent; and pushing all complexity into LLM calls, which makes system behavior harder to predict and debug.

Key implementation:

3. Role-Based Multi-Agent Debate System

VibeBot's Logic layer includes a debate system, which is one of the directions I care about most.

The debate system is not just multiple agents taking turns speaking. It has explicit roles, phases, and exit conditions:

  • Oracle: a read-only expert witness before the debate, using tools and research paths to build a factual base.
  • Morpheus: the ETHOS dimension, focused on risk, security, principles, and long-term impact.
  • Trinity: the PATHOS dimension, focused on users, creativity, adoption friction, and experience.
  • Neo: the LOGOS dimension, focused on logic, data, technical feasibility, and execution efficiency.
  • Synthesizer: the neutral adjudicator that integrates disagreement, consensus, risks, and final recommendations.

The system includes voting, cross-examination, synthesis, safety veto, and HITL interrupt/resume. When Morpheus finds a critical risk, it can trigger a safety veto. Oracle output is passed through PromptGuard and ExternalContentWrapper before entering debate context, so external content is not treated as trusted instructions.

I do not want every complex task to enter debate by default. Debate is a high-cost path, so it is controlled by deterministic routing and task-complexity judgment in the Access layer.

Key implementation:

4. Deterministic Routing First, Not LLM Routing First

Many agent frameworks tend to route tasks through a supervisor LLM. VibeBot makes a different choice: deterministic routing handles most clear cases first, and multi-agent orchestration is used only when deeper reasoning is justified.

The Access layer routes based on the output of HybridEvaluator:

  • Complexity: simple, medium, complex, multi_step
  • TaskType: general, analysis, decision, research, execution, and others

Tasks then move into different paths:

  • Simple or medium tasks: direct Responder path.
  • Complex analysis or decision tasks: DebateOrchestrator.
  • Long-range multi-step tasks: LongRange / PlanExecuteReplan.
  • Research tasks: ResearchCoordinator.
  • Tool-heavy tasks that are suitable for debate: Oracle pre-debate research when available.

The reason is straightforward: not every task deserves multi-agent debate, and not every decision needs another LLM call. Deterministic routing reduces cost, improves controllability, and makes behavior easier to inspect.

Key implementation:

5. Cornell-Style Dynamic Context Assembly

I do not treat prompts as one long string that keeps getting appended. I designed a Cornell-style dynamic slot assembly structure.

VibeBot splits dynamic context into slots:

  • user_task
  • active_knowledge
  • channel_context
  • conversation_history
  • debate_context
  • intent_summary
  • conversation_summary

Different task modes get different budget allocations. Simple conversations put more weight on history. Knowledge-heavy tasks allocate more budget to active_knowledge. Multi-agent debate keeps more debate_context.

The most important parts are waterfall trimming and user-input protection:

  • user_task is a P0 slot and is generally not trimmed by waterfall.
  • EnsureMinUserTask guarantees that the current task receives a minimum budget.
  • TrimWaterfall trims P2 content such as history, intent, and debate context before touching P1 content.
  • History trimming removes older messages first.
  • Cornell output keeps a cache-safe order, putting more stable knowledge and channel context earlier while keeping the current task closer to the end.
  • After summarization, CornellFinalize preserves slot structure so compression does not scatter key context.

The point is not to make prompts look more complex. The point is to protect upstream LLM execution quality: under context pressure, the latest task and the user's original intent should be preserved as much as possible, while knowledge, history, debate context, and channel information yield according to priority.

In the current implementation, Skills have moved from the old skill_directives slot into Eino Skill middleware. Cornell remains responsible for dynamic context, while Skills are progressively loaded when needed.

Key implementation:

6. Tool, Skill, and Self-Iteration

In VibeBot, I do not merge Tool and Skill into one concept.

My current model is:

  • Tool is executable capability. It performs external actions such as file, network, browser, MCP, or dynamic tool calls.
  • Skill is reusable procedural knowledge. It describes how a class of tasks should be judged, organized, and executed through tools.
  • Memory records runtime experience, failure patterns, decisions, and observations.
  • Knowledge distills relatively stable knowledge items and relationship graphs.
  • ALP places these assets into an observable, evaluable, and iterable lifecycle.

I use this table to constrain the boundaries:

Asset Type Essence Form Validation
Tool Executable atomic capability Go function / Python script / dynamic tool success, failure, exception
Skill Procedural knowledge SKILL.md + optional resources task outcome, trigger quality, scorecard
Memory Raw experience record session, event, observation, solution completeness, retrievability
Knowledge Distilled reusable cognition knowledge item, graph, index actionability, citation count, reinforcement signal

VibeBot Skills are not long prompt fragments hard-coded into the system. They are file-based assets centered on SKILL.md. The Skill system supports filesystem scanning, frontmatter metadata, content hash, enable / disable, token budget, allowed-tools filtering, scorecard / delta gates, and progressive loading through Eino skill middleware.

One important choice in Skill Framework v2 is that it stays compatible with the mainstream SKILL.md ecosystem, but does not reduce Skills to "prompt packs". In VibeBot, SKILL.md is the minimal useful unit, while fields such as pattern, allowed-tools, invocation-policy, activation, hooks, permissions, authorship, and quality-scorecard provide progressive enhancement.

The permissions field deserves a boundary note: in the current implementation, it is closer to declarative metadata and future governance input than a complete permission sandbox. Runtime safety constraints are handled by SecurityMiddleware, AgentPolicyGuard, RequestClassifier, dynamic-tool risk assessment, and allowed-tools filtering.

This gives Skills three meanings at once: procedural knowledge for agents, scheduling contracts for the runtime, and evaluable assets for ALP. VibeBot filters Skills by tool availability, priority, exclusive-with, maximum active count, and token/char budget. For machine-generated Skills, scorecard and delta are used for down-weighting, so automatically distilled experience does not enter high-priority paths before validation.

Dynamic tools are also not "created once and usable forever". Dynamic Tool Manager handles generation, validation, registration, health checks, risk assessment, promote / deprecate, and related management. When a tool is deprecated, the system scans Skills that depend on it, attempts to repair allowed-tools, disables affected Skills when needed, and emits asset-iteration events.

In short: Tool is the action layer, Skill is the capability-organization layer, and ALP is the lifecycle layer. Self-iteration is not a single feature. It is the feedback that emerges across these layers.

Key implementation:

7. Memory / Knowledge / SQLite / File as SSOT

Many VibeBot designs follow one principle: files are the source of truth for assets, while SQLite is the indexing, retrieval, and runtime-state layer.

This choice comes from several judgments:

  • Agent assets should be directly readable and editable by humans.
  • Files work naturally with Git, diff, backup, migration, and audit.
  • LLMs can read and write Markdown, JSON, YAML, and JSONL more directly.
  • SQLite corruption should not mean knowledge and skill assets are lost.
  • For a single-user desktop agent, local embedded databases fit the deployment complexity better than heavy external databases.

Memory is closer to an experience stream. It records facts, decisions, events, solutions, observations, skills, and other runtime outputs. Knowledge is closer to stable knowledge items, indexes, and graph. The Recall tool combines Memory, Knowledge, graph, FTS, embedding, and salience/scope rules to provide a controlled retrieval entry point for agents.

SQLite handles local-first indexing and state. The code uses WAL, split read/write pools, FTS, vec0, and related mechanisms to make it suitable for local retrieval and state management in a personal desktop agent. It does not replace file assets; it makes them searchable, connected, and recoverable.

Key implementation:

8. ALP: Asset Lifecycle Protocol

ALP is one of my core abstractions for self-iterating agents.

In VibeBot, ALP is not an isolated subsystem. It is a governance protocol that cuts across Tool, Skill, Memory, and Knowledge. The current ALP core state machine defines how assets are discovered, created, evaluated, and iterated. Concrete asset systems such as dynamic tools, Skills, and Knowledge then connect their own downgrade, deprecation, quarantine, repair, and retirement states through events.

Tool, Skill, Knowledge, and Memory can all be treated as assets. Assets should not only be created; they should enter a governable lifecycle:

Discover -> Create -> Evaluate -> Iterate -> Evaluate -> ...

The current code implements ALP infrastructure:

  • Asset lifecycle state machine.
  • Transition validation.
  • JSONL event recording.
  • Evaluator based on usage / success / failure / score.
  • Bridge between dynamic-tool events and unified AssetEvent.
  • Cascade rules for scanning and repairing affected Skills after tool deprecation.
  • Evolution metrics.

I do not describe this as a finished "fully autonomous self-evolving system". A more accurate statement is that VibeBot has built infrastructure for creating, evaluating, observing, repairing, and iterating agent assets.

I also introduced a lightweight convergence metric for self-iteration, such as EGL: newly created tools / total tool calls. It is not meant to prove that the system is "intelligent". It helps observe whether the tool library is moving from frequent creation toward stable reuse.

Key implementation:

9. Security as Part of the Runtime

In VibeBot, I do not treat Security as a final filter bolted onto the system. I try to place it in critical runtime paths.

The current Security layer includes:

  • PromptGuard: detects structured prompt injection and boundary-breaking signals.
  • OutputSanitizer: cleans credentials, tokens, secrets, and similar values from output.
  • RequestClassifier: classifies requests and tool calls by risk level.
  • AgentPolicyGuard: limits tool access and maximum risk level per agent.
  • ExternalContentWrapper: marks external content boundaries so external content is not treated as system instruction.
  • EnvPolicy, A2A guard, LogSanitizer, SecretStore, OutputCompliance, and related components.

Security also participates in dynamic tools and debate. Dynamic tool creation goes through PromptGuard, validation, risk assessment, and automatic risk classification. Oracle's external research output is scanned for injection and wrapped as external content. Delegate, research, oracle, and related agents are registered with AgentPolicyGuard to create runtime per-agent constraints.

The tradeoff is explicit: VibeBot is not currently a multi-tenant cloud sandbox, and should not be presented as a platform with complete enterprise isolation. It is closer to a local-first personal desktop agent safety baseline: risk classification, boundary marking, tool restrictions, output cleanup, and HITL reduce foreseeable risks.

Key implementation:

Architecture Overview

                     +----------------------+
                     |   User / Channels    |
                     +----------+-----------+
                                |
                                v
                     +----------------------+
                     |     Access Layer     |
                     | Matrix / Evaluator   |
                     | Deterministic Router |
                     +----+----------+------+
                          |          |
               simple / medium      complex / multi_step
                          |          |
                          v          v
                  +-----------+   +----------------------+
                  | Responder |   |      Logic Layer     |
                  +-----------+   | Debate / Oracle      |
                                  | Workflow / LongRange |
                                  +----------+-----------+
                                             |
                                             v
                                  +----------------------+
                                  |   Execution Layer    |
                                  | Tools / Skills       |
                                  | MCP / Dynamic Tools  |
                                  +----------+-----------+
                                             |
                                             v
+-------------------+       +-------------------+       +-------------------+
| Provider Runtime  |       | Context Runtime   |       | Asset Runtime     |
| Dynamic Catalog   |       | Cornell slots     |       | Memory/Knowledge  |
| Capability Router |       | Waterfall trim    |       | Skills/ALP/SSOT   |
+-------------------+       +-------------------+       +-------------------+
                                             |
                                             v
                                  +----------------------+
                                  |   Security Runtime   |
                                  | Guard / Policy/Risk  |
                                  | Boundary/Sanitizer   |
                                  +----------------------+

From Product Thinking to Code

Question My Answer Code
How should multiple upstream LLMs be governed? supplier-aware ProviderRouter + dynamic catalog + capability filter + group/prefer mechanism internal/providers
How should each agent call choose a model? DynamicModel resolves models based on task capability and multimodal content internal/eino/dynamic_model.go
Why include LiteLLM / OpenRouter data sources? To reduce stale manual model tables while keeping built-in fallback internal/providers/model_catalog.go
How should agents be layered? Access handles entry and routing, Logic handles complex reasoning, Execution handles tools internal/eino/access_agent.go
Does every route need an LLM? Deterministic routing first; complex tasks then enter Logic layer internal/eino/access_agent.go
How does multi-agent debate avoid losing control? Oracle builds a factual base, ETHOS/PATHOS/LOGOS split roles, Synthesizer adjudicates, safety veto and HITL control risk internal/eino/debate_orchestrator.go
How should prompts be organized? Cornell-style slots + token budget + waterfall trim + cache-safe ordering internal/prompts
How is user input protected? user_task is a P0 slot; current task and original intent are preserved while other slots yield by priority internal/prompts/budget_allocator.go
How should Skills exist? SKILL.md file assets + Eino middleware progressive loading + scorecard gate internal/skills
What is the relationship between Tool, Skill, and self-iteration? Tool is action, Skill is procedural knowledge, ALP provides lifecycle and feedback internal/tools / internal/memory
How does self-iteration avoid becoming a slogan? The loop is constrained by "what am I missing / how do I fill it / did it work", and ALP + EGL observe asset convergence internal/memory/asset_lifecycle.go / internal/tools/evolution_metrics.go
Is the database the source of truth? Files are SSOT; SQLite is indexing, retrieval, and runtime state internal/storage
Where does Security belong? In runtime, tool calls, dynamic tools, debate, and agent policy paths internal/security

Timeline

This project was not generated in one pass. It evolved continuously.

  • 2026-02-24: early project version formed; Memory Core System completed.
  • 2026-02-25 to 2026-02-28: 0.1 / 0.2 exploration of Channels, Agents, Providers, Tools, Security, Embedding, MCP, A2A, and related modules.
  • 2026-03-02: migrated to v3 architecture; introduced Eino, Asynq, CLI + daemon dual process, and gRPC skeleton.
  • 2026-03-31: implemented two-dimensional deterministic routing with Complexity x TaskType.
  • 2026-04-01: advanced the self-iteration loop, Oracle pre-fetch, Channel Prompt Slot, and related capabilities.
  • 2026-04-10 to 2026-04-14: upgraded Eino and activated ToolReduction, Skill fork, Workflow, Knowledge, and Skill Framework v2.
  • 2026-04-24 to 2026-04-27: enhanced Provider / Supplier / Onboarding and added platform-specific integration for MiniMax, Moonshot/Kimi, and others.
  • 2026-05: WebUI, execution trace visualization, and dependency upgrades.

These dates are mainly verifiable through git history. Unpublished historical spec documents record many design starting points, but this README is based on code and commit history.

Tech Stack

  • Go 1.26
  • Eino ADK
  • gRPC / Protobuf
  • SQLite / FTS / vec0
  • Asynq / Backlite
  • Vite / TypeScript / Lit
  • WebUI static assets through go:embed
  • Multi-LLM supplier integration

WebUI

This README treats WebUI as one of the current main entry points, instead of presenting CLI as the default experience.

VibeBot's WebUI is not a demo page separate from the backend. It is an HTTP gateway embedded in the daemon. It reuses backend services through an internal gRPC connection and exposes SPA, REST API, and SSE streaming responses. Current WebUI-related paths cover sessions, chat, interrupt / resume, dashboard overview, config reading and safe fields, onboarding, supplier catalog, model config saving, and provider testing.

This is why my current focus is "daemon + WebUI" rather than CLI. WebUI is better suited for provider management, model selection, session interaction, and future visualization of execution state and capabilities. CLI still has value, but it is not the main experience I want to highlight at this stage.

Key implementation:

Quick Start

VibeBot is still experimental. The following build and run steps assume a standard Linux environment with Go, Node.js / npm, make, and at least one usable LLM provider configuration.

1. Prepare Configuration

The config file name is vibebot.jsonc. In Linux environments, the load and override order is:

  1. System config: /etc/vibebot/vibebot.jsonc.
  2. User config: ~/.vibebot/config/vibebot.jsonc.
  3. Project config: if .vibebot/ is found by walking upward from the current directory, <workspace>/.vibebot/vibebot.jsonc is loaded with the highest priority.

On first startup, if the user config does not exist, VibeBot creates a seed config that preserves built-in defaults. Before actual use, add at least one model config with an API key:

export OPENAI_API_KEY="sk-..."
{
  "model_list": [
    {
      "model_name": "gpt-4.1-mini",
      "model": "openai/gpt-4.1-mini",
      "api_key": "${OPENAI_API_KEY}",
      "api_base": "https://api.openai.com/v1",
      "supplier": "openai",
      "model_group": "default",
      "timeout": 60
    }
  ],
  "webui": {
    "enabled": true,
    "addr": ":7780"
  }
}

model_name is VibeBot's internal model alias. model uses the supplier/model_id form. model_group can later be used to let different agents, bindings, or tasks prefer different model groups. OpenAI-compatible services can usually be connected through supplier and api_base.

2. Build and Run daemon + WebUI

In a Linux shell:

make build-daemon
./bin/vibebotd serve --webui

Then open:

http://localhost:7780

3. Web Frontend Development

make web-dev

This starts the Vite development server and is useful for frontend UI work. For the full WebUI experience, use the daemon-embedded gateway through vibebotd serve --webui.

Build frontend static assets only:

make web-build

Build both CLI and daemon if needed:

make build

More configuration references:

Project Layout

vibebot/
|-- cmd/
|   |-- vibebot/        # CLI entry point; not the current development main path
|   `-- vibebotd/       # current daemon entry point
|-- internal/
|   |-- agents/         # HybridEvaluator and traditional agent components
|   |-- eino/           # Eino-based Agent Runtime
|   |-- providers/      # multi Provider / Supplier / Model routing
|   |-- prompts/        # Cornell context assembly
|   |-- memory/         # Memory, ALP, reflection, lifecycle
|   |-- knowledge/      # Knowledge store / graph
|   |-- skills/         # Skill registry / Eino backend
|   |-- tools/          # tool system and dynamic tools
|   |-- security/       # Prompt guard / risk policy / output sanitization
|   |-- channels/       # third-party channel abstraction
|   |-- grpc/           # gRPC server/client
|   `-- webui/          # WebUI gateway
|-- builtin/
|   |-- agents/         # built-in agent definitions
|   |-- skills/         # built-in SKILL.md files
|   `-- workflows/      # built-in workflows
|-- api/proto/          # Protobuf API
|-- web/                # Vite / Lit WebUI
`-- configs/            # example configs

VibeCoding and Project Method

To me, VibeCoding is not just "letting AI write code". It is a high-frequency feedback method for product and architecture exploration:

  1. Write design hypotheses in documents.
  2. Land them quickly with AI coding tools.
  3. Correct judgment through real code, tests, runtime results, and review.
  4. Distill the new understanding back into architecture and documents.

This process fits agent-system exploration because agent systems are full of uncertainty. Many design choices only become clear after they are implemented, run through real paths, and debugged.

I also intentionally avoid writing this README as overly promotional "code social" copy. VibeBot can be attractive, but that attraction should come from structure, tradeoffs, and real implementation, not slogans, animations, or exaggerated promises.

People I Want to Talk To

I hope VibeBot attracts people interested in:

  • Agent Runtime design
  • Multi-agent orchestration
  • Provider routing / model orchestration
  • Context engineering
  • Prompt architecture
  • Boundaries between Memory / Knowledge / Skill / Workflow
  • Self-iterating tools and capability assets
  • Agent Security and local-first architecture
  • How AI product managers can use code to validate system design

If you are thinking about similar problems, I would be glad to talk.

Acknowledgements

VibeBot is built on ByteDance's open-source Eino framework. The project was developed mainly with Qoder, and earlier with Trae. Its design was also influenced by multiple open-source agent projects, AI coding tools, Skill Framework ideas, and research directions around self-evolving agents.

License

No license has been selected yet.

Until a license file is added, this repository does not grant an open-source license by default. The code can be read and discussed, but rights to copy, distribute, modify, or use it commercially are reserved by the author.

About

An experimental multi-agent runtime built through VibeCoding, exploring provider-aware LLM routing, deterministic agent orchestration, Cornell-style context assembly, file-based Skills, Memory/Knowledge, ALP self-iteration, and local-first security.

Topics

agent-runtimecontext-engineeringeinollm-routingmulti-agentself-iterationvibecoding

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages