AgentBridge

AgentBridge (codename "AGENT") — AI personal assistant that promises to replace humans in office work

Add agentic power to your work! An AI personal assistant that automates tasks and your work without sacrificing privacy. We're happy to put this powerful tool in your hands to automate your business while reducing staff costs, providing you with the most advanced AI technology in the office automation industry.

AgentBridge is a self-hosted server that runs its own AI agents behind two primary interfaces in a single process: a full-screen chat terminal (TUI) and an HTTP API that speaks the standard OpenAI protocol, so any OpenAI-compatible client drives the same agents.

Chat in the terminal while scripts, bots, and apps use the same agents on the same port: same process, same conversations, no bridges, no synchronization.

To be explicit about what the compatibility is and is not: AgentBridge is OpenAI-standard on the outside, not on the inside. It *is* a standard OpenAI server to any OpenAI client — SDKs, bots and scripts talk plain POST /v1/chat/completions and reach the same agents. It does not run on a standard agent system: the agent core is our own engine (AIOrchestrator/AgentHarness), and its defining concept is that an agent's abilities are compiled .NET assemblies loaded as plugins from the Tools/ folder and driven in-process — no interpreters, no remote tool servers, no standard agent glue between the agent and its actions. That is the Universal Tool System described below, and it is the architectural difference that sets this product apart.

It is the first agentic harness system for next-generation artificial intelligence that introduces significant innovations, raising the bar for all competitors in the industry. The system encapsulates agentic functions in a well-designed sandbox that prevents companies from suffering damage from an AI that is not properly controlled, while at the same time allowing them to entrust real business tasks to the AI, with a very high level of privacy and confidentiality.

AgentBridge stands apart from the harnesses you are familiar with because it is designed to let even people with no technical skills — your grandma, for example — use it without risking damage: file actions are reversible thanks to versioning, the agent is confined to a space bounded by guardrails built in by design, and no code-agent features are provided, precisely to prevent code from being created or executed. It can also be supplied together with our cloud platform, which synchronizes the file area in real time with a private, encrypted cloud located within your own company. In short, it is a product any employer can make available to their employees to support office work and make business processes more efficient. With traditional harnesses, a badly worded prompt could destroy documents, wipe the work drive, or cause other kinds of damage; our focus, by contrast, has been on creating a safe tool for office use.

Why teams choose this architecture

AgentBridge is built on the AIOrchestrator library model: one runtime, one agent core, and one consistent operational flow across terminal and API. The result is faster execution, lower integration overhead, and stronger control than traditional multi-server MCP setups. Read the white paper: Why the AIOrchestrator Library Model Outperforms Traditional MCP Deployments.

The architecture: one solution, and everything in it is a plugin

AgentBridge is not a single project. It is a solution — a set of .NET projects that form one whole — and the repository you are reading is only the *host* that assembles it. The other pieces live in repositories of their own, and each one is a plugin: a library that gives the agent one family of abilities.

flowchart TB

subgraph Host["AgentBridge — the host (this repository)"] TUI["Terminal UI · Web GUI · API"] LOOP["Agent loop (AgentHarness)"] end subgraph Plugins["Tools/ — the plugins folder"] DOC["OfficeTool → .docx .xlsx .pptx .pdf"] WORD["DocumentTool → Word"] SHEET["SpreadsheetTool → Excel"] DECK["PresentationTool → PowerPoint"] MORE["PodcastTool · MapTool · FreeCADTool ErpTool · OdooTool · PowerBITool …"] end TUI --> LOOP LOOP -- "direct method call in-process, no protocol" --> DOC LOOP --> WORD LOOP --> SHEET LOOP --> DECK LOOP --> MORE

No project references a plugin at compile time. The host hands the agent tool *names*; the plugin host scans the plugins folder (Tools/, next to the executable) at startup, loads the assemblies and resolves those names to real types at runtime — then hot-adds any plugin that appears later, 30 seconds after it lands. Adding an ability means dropping a folder in: no rebuild, no registration, no service to start, no schema to keep in sync.

The idea: the agent calls software, not a protocol

The mainstream way to make an agent agentic is MCP: the model speaks JSON-RPC to a separate process, which does the work and answers. AgentBridge does the opposite, and that is why this product is a solution of libraries instead of a bundle of servers.

The agent uses the library directly. It has to create or modify a Word document? It calls the library that edits Word documents — exactly the way any application calls a low-level library — and gets the result back as a value, in the same process, as a native method call.

Concretely, what changes:

• No protocol hop. No second process, no HTTP round-trip, no serialization between the agent and its action: a tool call *is* a method call. The failure modes of a protocol — timeouts, transport errors, version skew between client and server — simply do not exist.
• Granular control, not a reduced surface. The agent drives the real API of the library, not the handful of endpoints someone decided to expose: it can style a run of text, set a page break, keep a template's numbering — every parameter the library accepts.
• Deterministic interfaces. The tool interface is derived from the compiled code, so the model is offered the methods that exist and only those: no invented endpoints, no drifting schema.
• Type-safe errors. A failure arrives as a .NET exception that the harness catches and reports back in words the model can act on — not as an opaque protocol error.
• Context economy. Only the plugins that are enabled exist for the agent. A disabled plugin is absent from the catalog entirely: it costs zero context tokens and cannot be hallucinated, because for the agent it does not exist. Abilities are not paid for twice — once in the prompt prefix on every turn, and again when they are unused. The agent cannot switch one on either: nothing in the tool set writes the tool policy, so what an agent is allowed to do stays your decision — taken from /tools, from tools.json, or from the tools field of an API request.
• One artifact, no drift. The tool and the code it calls are the same assembly, built and shipped together.
• A sandbox around every call. Every tool call passes through the harness, which enforces the action perimeter structurally — no plugin method can step outside it.

MCP solved a real problem: reaching software you cannot link against, written by someone else, running somewhere else. As the *general* architecture of a system you build yourself, though, it puts a protocol where a function call belongs, and pays for that in latency, in configuration and in context window. Here the software is ours, it is compiled, and it sits on disk — so the agent gets the libraries themselves, and the architecture the agent follows is the one programmers already use.

MCP stays in the product as an interoperability channel, not as an internal one: outside clients can drive these agents over MCP (Use AgentBridge as an MCP server), and the agent can reach third-party MCP servers it is given. What it never does is speak MCP to its own abilities — those are assemblies, called directly.

The plugins — each a repository of its own, each a compiled library:

• Documents — OfficeTool (real DOCX/XLSX/PPTX/PDF from a prompt), DocumentTool (Word: paragraphs, tables, headers, charts, images), SpreadsheetTool (Excel: cells, ranges, styles, charts, tables), PresentationTool (slide decks PPTX and HTML), OfficeSupportTool (document workflows from HTML content)
• Media and research — PodcastTool (script, TTS, mixing, RSS), MapTool, AllToMarkdown (any document format → Markdown)
• Engineering and business — FreeCADTool (parametric 3D CAD), ErpTool, OdooTool, PowerBITool
• Always in the front line — WebTool, FileTool, GitTool, TaskSchedulerTool and MalfunctionReporterTool ship inside the host, because every agent needs them on its first turn.

Writing one yourself is the whole integration: derive from BaseAgentTool, build, drop the folder into Tools/, and the agent can use it. How the pieces fit together — the system tools inside the engine, the plugins loaded from Tools/, and how a name becomes a type — is described in AgentBridge → AIOrchestrator → tools.

Install & download

The Download for your OS button detects your platform and starts the right archive (~460 MB, self-contained — no .NET installation needed, Kokoro TTS voices included). Prefer the terminal? One line is enough:

The one-liners download the latest release for your platform into