RubyLLM 2.0: The Agentic Loop, Exposed
RubyLLM 2.0 breaks the sealed agent loop from 1.x into explicit Ruby verbs so you can control model calls, tool execution, persistence, batching, cancellation, and resumable runs.

RubyLLM 2.0 breaks the sealed agent loop from 1.x into explicit Ruby verbs so you can control model calls, tool execution, persistence, batching, cancellation, and resumable runs.

RubyLLM 2.0 exposes the agentic loop as explicit verbs (ask_later, generate, run_tools, step, complete?), letting you control each model/tool round.
Each agent turn can be one job: persist messages, run a single step per job, and resume safely after restarts or failures.
# What this change is
# The verbs you get
These verbs compose: ask is ask_later followed by complete (or repeated step calls). That decomposition is purposeful: it gives you hooks between model and tool rounds for batching, human approval, logging, or persistence.
# Why you'd use this
# One move per job: reliable, resumable runs Because each verb reads and writes persisted messages, you can implement an agent as a chain of jobs where each job performs a single turn. Example pattern: schedule an AgentTurnJob that loads the chat, calls chat.step, and enqueues itself again unless chat.complete?. Benefits:
If you use Rails 8.1 ActiveJob Continuations, you can checkpoint after each move and survive redeploys without managing an external cursor.
# Cancellation and stopping
break if handed_off? # your own stop condition
If you instead want exactly one tool call per model response, use chat.with_tool_options(calls::one). For total budget control, count your step or generate calls in the loop you control.
# Practical patterns
RubyLLM 2.0 turns the agentic loop into explicit, testable, and resumable Ruby code so you can integrate it into job queues, web controllers, and multi-process systems without hidden control flow.
I released Omakase 0.2 , a small agent framework on top of RubyLLM about 800 lines. The idea is that an agent is an ordinary Ruby object: its fields are state, its public methods are what the model can call (no tool registry, no JSON schemas to keep in sync - describe above a method is the description the model reads),

Originally appeared on Carmine Paolino . RubyLLM 2.0 is almost ready. It isn’t out yet, but it will be soon, and I have been looking forward to showing you what is in it. There is a lot in this release. Too much for one enormous announcement, and most of it deserves more than a bullet point. So this is the first in a s

LLM + Tools ≠ Agent I used to think an AI agent was simply: LLM + tools = Agent After exploring agentic system design, I’m starting to see it differently. The LLM is only one component. The real engineering challenge is designing the execution loop around it. A basic LLM application looks like: "Input → LLM → Response"
llm.rb is an advanced runtime for building agentic AI applications on CRuby. It has zero runtime dependencies by default, supports concurrent and parallel tool execution and has a single coherent API that spans 14+ providers.
That second question isn't a retrieval problem — it's a computation problem that depends on live, structured, user-specific data. This is exactly the gap agentic RAG closes: it keeps the semantic search RAG is good at, and bolts on tool calls (via MCP) so the agent can reach into live systems, fetch real numbers, and r
Enterprise Document Intelligence [Vol.1 #13bis] - The four bricks return useful results most of the time. Loop engineering is what the system does the rest of the time: when retrieval misses, when generation fails the schema, when the listing comes back incomplete, when an API call times out. Three control surfaces (tr
Loading more related stories...
Open the app view to save this story, compare related coverage, and continue from the same source.