Bring your existing C++ code into AI agent workflows — without rewriting it.
Declare a function once. Get an AI-agent tool, a CLI command, and a cross-language plugin — automatically.
cppAgent is a C++ integration layer built on the LingoFuse mesh, the LingoFuse-Tools code generator, and a thin Python service layer. It exists for one reason: C++ systems are fast, battle-tested, and hard to glue into modern AI workflows. cppAgent removes the glue.
You have working C++ code. It might be a pricing engine, a simulation core, a network scanner, a batch processor, or a legacy system that nobody wants to touch. You want AI agents, CLI users, and other languages to call it — without rewriting the code, without writing an MCP server, and without hand-maintaining an HTTP bridge.
This is what cppAgent is built for.
A portfolio manager asks the internal AI assistant:
"Run 10,000 Monte Carlo paths on Portfolio A and summarize the 95% VaR."
The assistant calls your C++ run_monte_carlo function through cppAgent. The result comes back in seconds.
flowchart LR
A["Portfolio Manager<br/>asks a question"]
B["AI Assistant<br/>calls the tool"]
C["C++ Pricing Function<br/>runs the math"]
D["Answer<br/>back in seconds"]
A --> B --> C --> D
No MCP server. No REST wrapper. The function was declared once.
Roles
- C++ maintainer — declares pricing functions.
- Platform engineer — runs the agent runtime and local LLM service.
- PM / Researcher — asks questions in natural language.
Outcome — Fast, auditable risk analysis. Sensitive data stays inside the network.
A data scientist works in Python. A front-end engineer works in JavaScript. Both need to call the same C++ simulation engine.
Before cppAgent — two integration projects, two sets of bindings, two things to break when the C++ API changes.
With cppAgent — the C++ team declares the function once. Everyone else just calls it.
flowchart TB
DECL["One C++ Declaration"]
DECL --> PY["Python Notebook"]
DECL --> JS["JavaScript Dashboard"]
DECL --> CLI["CLI Script"]
DECL --> AI["AI Agent Tool"]
Python consumer:
from lingofuse import simulation
result = simulation.run_scenario(scenario_id="rate_shock_200bp", paths=50000)JavaScript consumer:
const result = await simulation.runScenario({
scenario_id: "rate_shock_200bp",
paths: 50000
});Same function. Same result. No duplicated wrappers.
A security analyst needs to check a binary against internal malware signatures. The binary cannot leave the secure enclave.
The analyst asks the internal assistant. The assistant calls a local C++ scanning tool. Nothing leaves the network.
flowchart LR
A["Analyst<br/>asks a question"]
B["Internal AI Assistant<br/>local LLM"]
C["C++ Scanner<br/>reads the binary"]
D["Answer<br/>binary never moves"]
A --> B --> C --> D
Why this works — llm_service runs a local model. llm_proxy forwards plain text to an approved internal endpoint. Public cloud LLMs are never contacted.
Who needs this — financial services, healthcare, defense, any team with data residency rules.
A developer opens a pull request that changes a lock-free queue. CI runs:
cppagent review --diff HEAD~1 --checks concurrency,memory,apiCI posts a review comment:
"Potential ABA risk in
pop().compare_and_swapis called without a version tag. Seequeue_stress_test."
flowchart LR
A["Developer<br/>pushes PR"]
B["CI<br/>runs cppagent review"]
C["C++ Tools<br/>symbols + call graph"]
D["Review Comment<br/>specific and actionable"]
A --> B --> C --> D
What makes this possible — you declared symbol lookup, call graph, test selection, and benchmark functions. cppAgent turned them into agent tools and CLI commands.
A large enterprise has C++ systems everywhere: trading engines, real-time risk, simulation platforms, network appliances, legacy batch processors.
Instead of building a custom AI integration for each one, the platform team defines a standard cppAgent pattern. Each system declares its safe functions once.
flowchart TB
subgraph SYS["C++ Systems"]
TRADE["Trading Engine"]
RISK["Real-Time Risk"]
SIM["Simulation Platform"]
NET["Network Appliance"]
BATCH["Legacy Batch Processor"]
end
subgraph PLAT["Shared Agent Platform"]
DISC["Tool Discovery"]
PERM["Permission Control"]
AUDIT["Audit & Logging"]
end
SYS --> PLAT
Result — one integration pattern. Centralized audit. Reusable tools across agents. Lower maintenance cost than custom bridges.
Four stages. Each one is a separate concern.
flowchart LR
A["1. Declare<br/>C++ function"]
B["2. Register<br/>on the mesh"]
C["3. Agent calls<br/>as a tool"]
D["4. Anyone calls<br/>from any language"]
A --> B --> C --> D
Stage 1 — Declare. Add a declaration in C++ for a function you want to expose. Nothing else.
Stage 2 — Register. cppAgent registers the function on the LingoFuse mesh and generates three artifacts from the same declaration.
flowchart TB
DECL["C++ Declaration"]
DECL --> TOOL["AI-Agent Tool Schema"]
DECL --> CLICMD["CLI Command"]
DECL --> PLUG["Cross-Language Plugin"]
Stage 3 — Agent Calls. An AI agent sees the tool like any built-in capability. The mesh routes the call to your C++ function.
Stage 4 — Anyone Calls. Python, JavaScript, CLI, CI — all reach the same function through the mesh.
| Component | Language | Job |
|---|---|---|
agent_service |
C++ | Beacon. One per mesh. |
agent_api |
C++ | Tool provider. Replace with your functions. |
llm_cpp_tool + llm_client |
C++ | Client SDK + CLI / REPL. |
llm_proxy_tool.py |
Python | Server-side tool execution. Zero client changes. |
Supporting services: llm_service.py, llm_proxy.py, bridge.py, mcp_api_tool.py.
One request, four moments: intent, decision, execution, reply.
flowchart LR
A["Client<br/>asks: what is 12 + 34?"]
B["LLM<br/>picks tool: add"]
C["C++ Function<br/>runs add 12 34 → 46"]
D["Client<br/>receives: 46"]
A --> B --> C --> D
The client is unaware of the tool. Your C++ function is the only thing that actually runs.
| Item | Version |
|---|---|
| CMake | 3.16+ |
| C++ Compiler | MSVC 2019+ (Windows), GCC 9+ (Linux), Clang 10+ (macOS) |
| C++ Standard | C++17 |
| Python | 3.10+ (for the Python service layer) |
| LingoFuse | Latest main branch |
git clone https://github.com/PassByYou888/LingoFuse.gitThe C++ interface directory is LingoFuse/cpp/. It contains the five header and source files required by cppAgent, plus runtime libraries in LingoFuse/Binary/.
Pass the path to the C++ interface directory via -DLINGOFUSE_CPP_DIR.
Windows (PowerShell) — Visual Studio
cd LingoFuse-cppAgent\src
cmake -S . -B ..\x64 `
-G "Visual Studio 17 2022" -A x64 `
-DLINGOFUSE_CPP_DIR="..\..\LingoFuse\cpp"Linux / macOS — Makefiles
cd LingoFuse-cppAgent/src
cmake -S . -B ../build \
-DCMAKE_BUILD_TYPE=Release \
-DLINGOFUSE_CPP_DIR="../../LingoFuse/cpp"LINGOFUSE_CPP_DIR must point to the directory containing LingoFuse.h, LingoFuse.c, LingoFuse.hpp, lf_io.hpp, and json.hpp. There is no auto-detection.
Windows
cmake --build ..\x64 --config ReleaseLinux / macOS
cmake --build ../build -jExecutables are written into src/:
| Artifact | Type | Description |
|---|---|---|
agent_service |
Executable | Beacon / tool registry |
agent_api |
Executable | Tool provider template |
llm_cpp_tool |
Executable | C++ LLM CLI / REPL |
llm_client.lib / libllm_client.a |
Static library | Link into your C++ application |
lingofuse_c_wrapper.lib / .a |
Static library | C ABI dynamic loader |
Copy the LingoFuse runtime library from LingoFuse/Binary/ next to the executables:
| Platform | File |
|---|---|
| Windows | LingoFuse64.dll |
| Linux | liblingofuse.so |
| macOS | liblingofuse.dylib |
pip install -r requirements.txtStart four processes. Order matters: beacon first, tools next, then the backend, then the client.
flowchart LR
T1["1. agent_service<br/>beacon"]
T2["2. agent_api<br/>your tools"]
T3["3. llm_proxy_tool.py<br/>tool backend"]
T4["4. llm_cpp_tool<br/>client"]
T1 --> T2 --> T3 --> T4
# Four terminals, in this order
.\agent_service.exe # beacon
.\agent_api.exe # your tools
python llm_proxy_tool.py --backend-url http://127.0.0.1:1234/v1
.\llm_cpp_tool.exe --content "What is 12 + 34?" --keep| Document | What it covers |
|---|---|
| QUICK_START.md | Run the LLM in 15 minutes with the pre-built package. No compiler needed. |
| LingoFuse-cppAgent_Real_World_Application_Workflows.md | Real engineering workflows — quant pricing, cross-language reuse, private AI, AI-assisted C++ dev, enterprise platform. Who does the work, what triggers it, what the output looks like. |
| Document | What it covers |
|---|---|
| LingoFuse_LLM_Ecosystem_User_Guide.md | Four core application components, two tool execution paths, capability matrix, streaming protocol |
| LingoFuse_LLM_Proxy_Compatibility_Guide.md | 250+ OpenAI-compatible backends (cloud APIs, local servers, gateways, desktop clients) |
| Document | What it covers |
|---|---|
| LingoFuse_LLM_Service_CLI_guide.md | Local inference service (llm_service) — text-only, embeddable |
| LingoFuse_LLM_Proxy_CLI_Guide.md | Pure text forwarder (llm_proxy) — no tools |
| LingoFuse_LLM_Proxy_Tool_CLI_Guide.md | Tool execution bridge (llm_proxy_tool / LTB) — server-side tools |
| llm_cpp_tool_User_Guide.md | C++ command-line client — REPL, attachments, Structured Output |
| Document | What it covers |
|---|---|
| NVIDIA-Nemotron-3-Nano-Omni-30B-A3B-Reasoning-UD-IQ4_XS.md | Recommended multimodal model — download, quantization, deployment |
| Bridge_User_Guide.md | HTTP ↔ LingoFuse gateway and JSON repair service |
| Repository | Role |
|---|---|
| LingoFuse | Core cross-language mesh |
| LingoFuse-Tools | Declaration → code generator |
| LingoFuse-pasAgent-v3 | Reference agent implementation |
| LingoFuse-pasAgent | Earlier generation |
MIT.
Maintainer: LingoFuse Team Status: Active development