Series
Learning Embabel by building with it, in order — planning, durable sessions, testing without a model, tools, human-in-the-loop, tracing, exposing it over MCP.
Part 1
My first afternoon with Embabel, the JVM agent framework. I added one action too many, the planner quietly stopped early, and a cryptic get(...) must not be null taught me how GOAP, goals, and AgentInvocation actually fit together.
Part 2
The non-deterministic part of an agent is the LLM. Box it out and the rest is ordinary, deterministic code you can test. Here's how I test Embabel agents on the JVM without spending a single token.
Part 3
An LLM cannot know a live account balance, and in banking a confidently hallucinated number is a disaster. The fix is a tool. Here's how @LlmTool works in Embabel on the JVM, plus the one API gotcha that cost me a compile.
Part 4
In regulated work the dangerous agent is the one that acts without asking. Here's how I made an Embabel agent pause for human approval before moving money -- with the approval built into the type graph, not an if-check.
Part 5
I pointed my Embabel agents at a local Grafana LGTM stack and saw nothing. Three configuration gotchas later, every GOAP planning step, LLM call and tool loop shows up as a span in Tempo. Here is the full walkthrough, with screenshots.
Part 6
Turning my JVM agents into MCP tools took one dependency and one annotation. It also took three silent failures -- a starter that suppresses the web server, a shell that eats your CLI flags, and an annotation default that publishes exactly zero tools without telling you.
Part 7
My agent refused to run a single action. The @Condition gate was FALSE and nothing in the agent could ever make it TRUE, because Embabel builds an action's effects from what you declare, not from what your condition reads.
Part 8
An Embabel blackboard lives and dies with a single agent process. A Context is the thing that outlives it - and because it seeds the blackboard before planning starts, it changes which actions actually run.
Part 9
Ask the same question twice in one session and the planner drops a step. Not a cache — a consequence of A* refusing to schedule an action whose output is already on the blackboard, for better and for worse.
Part 10
When an Embabel action needs two objects of the same type, binding becomes two declarations that must agree — and nothing cross-checks them. Get them out of step and you get a startup exception, an unreachable goal, or a confident wrong answer, depending on which half you forgot.