> ## Content Index
> Fetch the complete content index at: https://blog.meganova.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to Build Autonomous AI Agents with LibraOS: Practical Examples and Tutorials
- URL: https://blog.meganova.ai/how-to-build-autonomous-ai-agents-with-libraos-practical-examples-and-tutorials/
- Published: 2026-10-30T09:26:00.000Z
- Updated: 2026-10-30T09:26:00.000Z
- Author: Tracy Giang

"Autonomous" is an easy word to oversell. In this guide it means something specific: an agent that can take a goal, plan the steps, run them on its own, hand work between specialists and keep going while nobody watches, inside limits you set, with people deciding at the points that matter.

That's a ladder, not a switch. This guide climbs it with three practical examples from the public [LibraOS Cookbook](https://github.com/libraos/cookbook?ref=blog.meganova.ai): an agent that makes structured decisions, work that outlives a single request, and a team of agents that runs a whole mission. For each one it covers what the example shows, how it works, and what has and hasn't been verified.

## **The building blocks**

The Cookbook organizes autonomous work in five layers, each built on the one below:

| Layer                | Answers                                        | Example                                                                                  |
| -------------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------- |
| **Skill**            | What can an agent do?                          | search\_web, fetch\_url, knowledge\_search                                               |
| **Agent / employee** | Who does the work, with what role and rules?   | A market researcher with search\_web and fetch\_url                                      |
| **Pack**             | Who is on the team?                            | A director plus specialists, their knowledge and safety rules                            |
| **Mission**          | What must the team deliver, under which rules? | Workstreams, task limits, allowed tools, evidence rules, approval gates, report sections |
| **App**              | How does someone run it?                       | A mission console, or your own product calling the Runtime                               |

Autonomy grows as you move up. A single agent with skills answers and acts within one task. A pack gives you a team. A mission tells that team what to deliver and where it must stop for a person.

## **Example 1: An agent that makes structured decisions**

**What it shows.** Before an agent can act on its own, your code has to be able to trust its output. The [ticket-routing recipe](https://github.com/libraos/cookbook/tree/main/recipes/ticket-routing?ref=blog.meganova.ai) classifies raw support tickets into a typed `{reasoning, intent}` verdict that drives a routing rule. Your code acts on `intent`; it never parses free text.

**How it works.**

- **A schema the server enforces.** The agent is given an `output_type` JSON schema, with the allowed intents as an enum. LibraOS validates every reply against it before it leaves the Runtime. This runs on the agent chat endpoint, `POST /agents/v1/<agent>/chat`, which returns the parsed object as `output`.
- **One bounded retry.** With `on_violation=repair`, a reply that doesn't conform is re-prompted once with the schema, instead of failing outright.
- **A fast, narrow agent.** `brain=false` skips the planner and `tool_scope="none"` keeps the tool catalog out of the prompt, so a classification stays one short call.
- **An accuracy gate.** Before live traffic, run a hand-labelled set through it and read the misses. A schema-valid but wrong label is an evaluation miss, not an error.

**Status.** Tested against Runtime v0.2.2 with SDK 2.0.0\. Accuracy depends on the model your Runtime routes this tier to.

This is the first rung of autonomy: a decision your code can rely on, so it can route, escalate or act without a person reading every reply.

## **Example 2: Work that outlives a request**

**What it shows.** An autonomous agent often works longer than a browser tab stays open. The [async-jobs recipe](https://github.com/libraos/cookbook/tree/main/recipes/async-jobs?ref=blog.meganova.ai) submits work as a job, lets the client disconnect, and picks the result up later, even from another process.

**How it works.** The recipe uses the Runtime's native job routes:

| Operation | Route                                                                          |
| --------- | ------------------------------------------------------------------------------ |
| Submit    | POST /agents/v1/{agent}/jobs with body {message} and an Idempotency-Key header |
| Check     | GET /agents/v1/{agent}/jobs/{job\_id}                                          |
| Cancel    | DELETE /agents/v1/{agent}/jobs/{job\_id}                                       |

A job moves through `queued`, `running`, and then one of `done`, `failed` or `cancelled`. Three habits make it safe to walk away:

- **Save a receipt before you submit.** It holds the idempotency key and request, so a lost response can be retried without creating a second job.
- **Resume by ID.** Once the job ID is saved, recovery only reads that job; it never submits again.
- **Cancel on purpose.** A job that finishes while you cancel can win the race, so read the real final state afterward.

**Status.** The offline HTTP contracts pass. Real Runtime execution and durability on a tagged release are still to be recorded. The recipe proves recovery after a *client* restart; it does not promise that arbitrary work resumes after a Runtime crash. Check `/api/version` and idempotency support on your server first.

## **Example 3: A team that runs a mission**

**What it shows.** The top rung: one instruction becomes organized work across several agents. In the [Digital Marketing Team app](https://github.com/libraos/cookbook/tree/main/apps/digital-marketing-team?ref=blog.meganova.ai), a single request to a Head of Marketing employee turns into a small department that plans, divides and delivers a report.

**How it works.** The client makes one call, `POST /agents/v1/head-of-marketing/jobs`, and the Runtime does the rest:

1. **Plan.** The Head of Marketing's planner decides which specialists the mission needs and builds a task graph with explicit dependencies.
2. **Run.** A scheduler starts tasks whose dependencies are met, several at once, and records checkpoints.
3. **Hand off.** Each specialist passes structured output to the next, not raw chat.
4. **Pause for a decision.** When the mission reaches a real decision, dependent work waits for a person. The app resolves it with `POST /agents/v1/{lead}/jobs/{job}/decisions/{decision}`.
5. **Synthesize.** The lead writes one report, with sources and contributors drawn from runtime data.

The app's UI is driven by the job's event stream, so a browser can reconnect and replay what happened. The app's README describes PostgreSQL storing the event log and workflow checkpoints, which lets the Runtime resume an orphaned mission without redoing completed work. The README describes this design; a live recovery run has not been published yet.

**What you need.** Runtime v0.2.2 or later with workflows enabled (`LIBRA_OS_WORKFLOWS_ENABLED=true`), PostgreSQL, the app's sign-in client, and a model that returns structured JSON reliably and supports tool calls. The planner asks for the whole task graph in one JSON reply; smaller local models sometimes return a graph the Runtime rejects, and the mission fails before any task starts.

**Status.** Today the mission engine runs the marketing team only, with its prompts compiled in. Loading mission templates from your own packs is [proposed](https://github.com/libraos/libraos/issues/1660?ref=blog.meganova.ai), not available yet. The mission client has offline tests for streaming, replay, pending decisions and failures; a full mission run with a live model is tested separately.

## **Keeping people in control**

The more an agent does on its own, the more the stopping points matter. The Cookbook separates two approval mechanisms, and they are not interchangeable:

| Mission decision       | Tool action approval                                     |                                                              |
| ---------------------- | -------------------------------------------------------- | ------------------------------------------------------------ |
| Purpose                | Resolve a decision inside a running mission              | Authorize a pending action that changes something            |
| Where it's shown today | The marketing mission and its console                    | A dedicated tutorial is pending contract verification        |
| Success looks like     | The decision resolves and dependent work resumes         | The approved action runs once and returns a business receipt |
| Boundary               | An unauthorized caller is denied; the gate stays pending | A rejected action runs zero times                            |

An approval button in your UI is not proof that the caller had permission, or that an external action actually ran. Test both on your release.

The same rule from the LibraOS Security page applies at every rung: tasks that run inside the Runtime get its permissions, approvals and audit. Tools, shell commands and network activity outside the Runtime need their own enforcement. An agent that can reach a payment API from your own code is outside every gate described here.

## **Where to start**

Pick the rung that matches what you're building. Each example in the Cookbook names an observable success and a failure to check.

| Stage | Example                                                                                                             | You'll see                                                                                               | Check that                                                              |
| ----- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| 1     | [First Agent](https://github.com/libraos/cookbook/tree/main/get-started/01-first-agent?ref=blog.meganova.ai)        | Replies that keep conversation context                                                                   | Bad credentials and an unavailable model fail cleanly                   |
| 1     | [Ticket Routing](https://github.com/libraos/cookbook/tree/main/recipes/ticket-routing?ref=blog.meganova.ai)         | A schema-valid intent and a measured accuracy                                                            | An invalid schema is an error; a wrong label is counted as a miss       |
| 2     | Knowledge, Tools or Memory                                                                                          | Grounded answers, a signed tool receipt, or recall in a new conversation (live results not yet recorded) | Missing facts aren't invented; tool failures aren't turned into answers |
| 3     | [Async Jobs](https://github.com/libraos/cookbook/tree/main/recipes/async-jobs?ref=blog.meganova.ai)                 | A job ID that survives a client restart                                                                  | Lost responses, timeouts, failed and cancelled jobs                     |
| 4     | [Marketing Mission](https://github.com/libraos/cookbook/tree/main/apps/digital-marketing-team?ref=blog.meganova.ai) | An attributed final report and runtime events                                                            | Reconnection, task failure and a pending decision                       |

Stage 2 is a set of choices, not three steps to complete in order. The Cookbook's [Document Q&A](https://github.com/libraos/cookbook/tree/main/recipes/document-qa?ref=blog.meganova.ai) and [tool-calling](https://github.com/libraos/cookbook/tree/main/recipes/tool-calling?ref=blog.meganova.ai) recipes cover knowledge and tools.

## **Limits to plan around**

- **Versions matter.** The examples are pinned to Runtime v0.2.2 and SDK 2.0.0\. A Compose pin is not proof that every recipe passed a live run on that release; check the [validation record](https://github.com/libraos/cookbook/blob/main/docs/validation.md?ref=blog.meganova.ai) for each example.
- **Missions are early.** The mission engine runs one built-in team today. Custom mission templates are proposed, not shipped.
- **The model is part of the system.** Planning, structured output and tool calls all depend on a model that handles them reliably. Test with the model you'll run in production.
- **Autonomy needs its gates tested.** Approval paths, permissions and side effects should be checked on your release before anything runs unattended.

## **Conclusion**

Building autonomous agents with LibraOS is a climb, not a leap. Start with an agent whose output your code can trust, move long work into jobs you can recover, and only then hand a team a mission with clear gates for human decisions. At each rung, run the example's success and failure checks on your own release and model, and keep every side effect inside the Runtime where its controls apply.

> **Explore LibraOS:** [**libraos.com**](https://libraos.com/?ref=blog.meganova.ai)

## Sources

- [LibraOS Cookbook: concepts, learning paths, approval mechanisms and validation](https://github.com/libraos/cookbook?ref=blog.meganova.ai)
- [Ticket routing recipe](https://github.com/libraos/cookbook/tree/main/recipes/ticket-routing?ref=blog.meganova.ai)
- [Async jobs recipe](https://github.com/libraos/cookbook/tree/main/recipes/async-jobs?ref=blog.meganova.ai)
- [Digital Marketing Team app](https://github.com/libraos/cookbook/tree/main/apps/digital-marketing-team?ref=blog.meganova.ai)
- [Security & Private Deployment](https://libraos.com/security/?ref=blog.meganova.ai)

### **What’s Next?**

[**Sign up**](https://console.meganova.ai/register?referral=e0602d28&utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink&ref=blog.meganova.ai) and explore now.

🔍 **Learn more:** Visit [**our blog**](https://blog.meganova.ai/?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink) and [**documents**](https://docs.meganova.ai/?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink) for more insights or [contact us](https://www.meganova.ai/contact-us?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink) for a demo of how MegaNova can power your AI products.

📬 **Get in touch**: Join our [Discord community](https://discord.com/invite/QBTnGurDw4?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fai%5Flaunch&utm%5Fcontent=body%5Flink) for help or [Contact Us](https://www.meganova.ai/contact-us?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink).