You can already build an agent in any language you like. So why learn a new one? Because the hard parts of agent work are the same every time, and a language can solve them once, for everyone, in a way a library never quite manages.
The problem with gluing it together
A typical agent is a general purpose program holding a model SDK at arm's length. You build a prompt by concatenating strings. You send it. You get back text. You try to read that text as JSON, validate it, and recover when it is malformed. You wire up tools by hand and hope the model calls them with the right arguments. You add retries, timeouts, and spending limits as an afterthought. None of this is visible in the type of any function, so the compiler cannot help you, and the behaviour that matters lives in comments and conventions.
This is workable for a demo and fragile in production. The failure modes are quiet. A model returns a value you did not expect, a new branch is added but one call site is missed, a tool changes its shape, and nothing complains until a user hits it.
Types are the missing piece
Orchard treats a model call as an expression with a type. When you write gen as Severity, you get back a value of the Severity enum, guaranteed to be one of its variants. There is no parsing step and no malformed output to handle, because the runtime constrains generation to the type you asked for. You then branch with a match, and the checker refuses to compile until every variant is handled. The whole class of bugs that comes from reading model output by hand simply does not exist.
Tools and concurrency belong in the language
Calling tools and running work in parallel are not advanced features for agents. They are the normal case. Orchard makes them part of the grammar. A handler can delegate to an autonomous loop that decides which tools to call. It can spawn several tasks, do other work, and await them later, or run a batch with parallel and collect the results. The native tool packs for HTTP, the web, and the shell are available out of the box, and any server that speaks the Model Context Protocol can be used as a tool source. Because the runtime owns this loop, budgets, a circuit breaker, and tool limits apply automatically.
Develop offline, deploy anywhere
Orchard ships with a mock provider, so you can write and test a complete agent with no network and no API key. When you are ready for a real model, you change one line of configuration and point the same program at Anthropic, an OpenAI compatible endpoint, or a local model through Ollama. The same source then runs inside a Rust service, a C program, a Python application, or a browser tab, because the core is one Rust library wrapped for each target.
What we are aiming for
The ambition is straightforward to say and hard to earn: make Orchard the obvious choice for anyone serious about shipping an agent. We want the moment you describe what an agent should do to be the moment you have a program that is checked, testable, and portable. We want a beginner to get a working agent in an afternoon and a team to trust the same language with a system that runs every day. A language that is pleasant on the first page and still honest on the thousandth.
See for yourself
- Read the progressive guide and write your first agent in a few minutes.
- Look at what people build with Orchard.
- Check the roadmap to see what is coming.