What Is LibraOS? An AI Agent Runtime with Memory and Approvals

Adding AI to an app is no longer the hard part. A model can answer questions, summarize documents and draft replies, and today's app builders turn an idea into a working prototype quickly.

The hard part starts when real users arrive. The app now has to carry context from one session to the next, answer from your own documents, run tasks with several steps and tools, and keep a person in charge of actions that change data or reach a customer. That is the gap between an app with AI in it and an AI system ready for production.

LibraOS is built for that gap. It is the AI runtime for your apps: the execution layer that runs agents, memory, knowledge and tools beneath your own interface. Its short version is "Think. Remember. Act." Your app keeps its code and user experience, LibraOS handles the AI work, and you choose the model and where it all runs.

Your chosen model powers the responses. LibraOS connects those responses to persistent context, knowledge and actions, with policies, approvals and audit around them.

Where LibraOS sits in your app

Think of three layers:

Your app talks to the Runtime through supported APIs, and the Runtime talks to the model. You keep your source in your own repository and keep building in your own editor. You can add AI to an existing app or build from a starter.

Inside the Runtime

The Runtime has four parts:

Control applies to the tasks your app runs through LibraOS. You configure permissions, approval points and audit, then review the execution path before launch. In the Customer Desk concept on the LibraOS homepage (sample data), the assistant drafts a reply but keeps any credit or refund behind a person's approval.

One limit to plan around: recovery after an interruption depends on the workflow. Don't assume every agent or external action resumes on its own; check the durable-run limits before you design long-running tasks.

How the parts work together

Each part solves one problem. The value shows when they run in the same workflow. Take a support request like the ones in the Customer Desk concept on the LibraOS homepage (sample data): a customer writes in and asks for a refund on an order.

1. Agents read the request, plan the steps, and call the tools your app allows, such as an order lookup.
2. Knowledge retrieves the refund policy from your connected sources.
3. Memory brings in useful context from earlier sessions on the same case.
4. The agent drafts a reply and proposes the refund.
5. Control holds the refund at an approval point until a person reviews the evidence and decides.
6. Audit keeps a record of the task for later review.

The model writes the reply. Everything around it, the context, the sources, the tool calls and the approval, is what the Runtime runs. Without it, your team would build and maintain each of those pieces itself, for every app.

Bring your own model

LibraOS doesn't tie you to one model provider. You pick the chat and embedding models, and LibraOS handles everything around them. There are three ways to connect:

Before choosing open weights, read the model card: base model, publisher, license, modifications and hardware needs. LibraOS publishes its model repositories on Hugging Face, and its site explains what the fine-tuned, quantized and mirror labels mean.

Choose where it runs

The Runtime is free for personal use. Business production use falls under the commercial terms on the pricing page.

If you start in LibraOS Cloud, eligible accounts can also export the source and continue locally.

Security and control

LibraOS lets you decide three things: where your data lives, which models your app uses, and where actions need approval.

Reviewed actions. You configure permissions, approval points and audit for the tasks your app runs through LibraOS. Review the execution path before launch, and test it against your app's real actions.

AI firewall. Requests and responses can pass through three tiers of screening:

1. Pattern screening: rules catch configured injection patterns and sensitive-data formats.
2. Risk scoring: a classifier assesses requests and responses beyond the pattern checks.
3. Model review: a judge model evaluates ambiguous cases against your policy.

Screening reduces risk; it does not guarantee that every harmful prompt or response will be detected. Configure it for your models and workflows, then check both detection and task quality.

Where the controls apply. Tasks that run inside the Runtime get its permissions, approvals and audit. If you route only a model request through LibraOS, controls apply at that request. Tools, shell commands and network activity outside the Runtime need their own enforcement.

What a runtime doesn't do for you. Using LibraOS doesn't make an app secure or compliant on its own. You still review data flows, configuration, access, model providers and any components outside the Runtime. For regulated use cases, confirm the agreements, responsibilities and technical controls you need with the LibraOS team before deployment.

Measured overhead

A runtime sits in the path of every request, so its own overhead matters. LibraOS publishes a controlled benchmark on its homepage:

In the same 256-concurrency test, Agno ran 64 runs/s and LangGraph 8; LangGraph was run with langgraph dev, and polling affects its throughput. The benchmark uses a mock model, so it measures the runtime's overhead, not model speed. As the page itself says, these results do not establish production deployment superiority. Test with your own models and workload.

Getting started

The developer path has four steps:

1. Install. Start a Runtime from the binary or container images, and configure storage and model access.
2. Integrate. Connect your app with your server URL and a scoped credential. The Python SDK (pip install libraos-sdk) is a client; it connects to a running Runtime and does not install one.
3. Run. Send a message, inspect the result, and test knowledge access, tools and approval behavior for your workflow.
4. Ship. Review authorization, data boundaries, failure handling, operations and commercial licensing before rollout.

If you'd rather start from an idea, describe the app and build it from a starter, such as the Personal Assistant, then keep developing in your own repository. Runnable examples live in the SDK and Cookbook repositories. A VS Code extension is available in preview.

What you can build

• App ideas on the LibraOS homepage: a personal assistant that answers from your documents and carries context across sessions, a research workspace, and a support copilot.
• Interactive concepts with sample data: Customer Desk (CRM and ticket management), Investment OS and Legal OS.
• Private deployments: on-premise, private cloud, air-gapped or Canadian-jurisdiction setups, plus enterprise and OEM licensing through the LibraOS team.

Conclusion

LibraOS is the layer between your app and your model. It runs the agents, keeps context across sessions, retrieves from your sources, and puts approvals and audit around actions. You keep your code, choose your model, and decide where it runs: your servers, an isolated network, or LibraOS Cloud, now in private beta.

Explore LibraOS: https://libraos.com/

Sources

• LibraOS Products
• LibraOS homepage: Runtime and benchmark
• Models & Inference
• Security & Private Deployment
• Download
• Developers

What’s Next?

Sign up and explore now.

🔍 Learn more: Visit our blog and documents for more insights or contact us for a demo of how MegaNova can power your AI products.

📬 Get in touch: Join our Discord community for help or Contact Us.