Agentic Frameworks - by astle dsa - Theoretical Limits

Theoretical Limits

SubscribeSign in

Agentic Frameworks<br>Or different ways to make LLM API calls

astle dsa<br>Jun 10, 2026

Share

The agentic framework research has produced some very interesting results; from different topologies to different ways of using tool-calls, it has been one of the most fascinating and accessible areas of research in the AI landscape. In this essay, I’d like to talk about some core structures that sit at the heart of various agentic framework applications we have seen, and some (possibly) new directions I’d like to explore.<br>I.

We must, before anything else, define the most primitive tool we have: a simple text-in-text-out API call. Following that, we have perhaps the most important one: JSON or structured outputs. Taking these two API calls, we can come up with four different paradigms (methodologies?) for creating frameworks, and explore which ones accomplish certain goals better than a simple TITO API call.<br>1. The Sequencing Model<br>The first framework is also the simplest: just call the LLMs in succession, each time with a different task and tool combination, with the output from the previous call appended/fed into the subsequent call. This is a simple way of managing context and separating tool usage per API call.

API call in sequence<br>2. The Branching Model

The next framework is but a simple modification over the previous one, wherein we allow for two simultaneous LLM API calls to be made, assigned independent tasks which can be completed without dependency problems. This was one of the more widely implemented frameworks, especially in workflow settings. Almost all “agent“ implementations today follow this framework, using libraries like LangGraph, Mantra or n8n. This setup gives rise to structures like agentic trees and graphs, where each node is defined using a system prompt plus a tool-set. Most commonly implemented is a workflow graph setting.

API calls, branching<br>3. The Looping Model

Here we finally arrive at the most implemented, widely known and perhaps the most effective framework: looping the model. We start with an outer loop called the REPL, which repeatedly takes in the user’s request. Upon taking the request, a while loop is initiated, which calls the LLM API, performs tool call execution and feeds the outputs back into the context for the subsequent LLM API call. The loop only ends when either no tool is called (the LLM outputs plaintext) or there’s a special tool to stop the loop (this is an implementation detail)1. Very common and widely known examples: Codex, Claude Code and Pi.

The outer REPL loop, and the inner while loop<br>4. The Recursive Model

Perhaps the latest framework, and one which created some buzz, was the RLM or the recursive language model setup. Though it sounds like there’s a new architecture, this is but a simple engineering of the LLM API call. As mentioned in the original paper/blog, we simply allow a single LLM API call the ability to access a REPL environment, store the context and request it as a variable in that environment, and provide a special tool, which allows it to make another API call to a language model, so that it can delegate tasks, break down contexts and perform other actions. This is, as is obvious, an agentic framework but with a special tool: the ability to call itself. Hence recursion. This gives rise to multi-agent setups (which currently Claude Code can carry out). The main point of the authors is that language models, which are generally trained on tool-calling, must be specifically trained on this one, which might lead to improvements. Here’s their follow-up paper, in which they did fine-tune a model2.

An LLM making other LLM API calls

II.

With these, we basically cover the core primitives of different methodologies, and another great step forward (at the cost of high token usage) would be to mix and match these structures and observe what works best. A few ways to mix and match:<br>The simplest approach would be to replace the LLM API call with the agent abstraction, which means every framework above can be re-wired with the agent framework, calling agents in sequence and branching instead of making API calls to LLMs. One might wonder, however, what the advantage of that would be, since the agent (I am using this henceforth to mean LLM API call plus tools on a loop) is good at handling all the tools at once? One thing is the environment or workspace. A single agent can be given access to a particular environment only, and multiple such agents can be tasked with performing certain actions (with the given topologies) within their own respective environments, and their results can be communicated through certain mediums (I’d call this the Swarm Model).

Although I do not see much advantage here, only marginal, we can replace each LLM API call within the agentic loop with a recursive API call, the one used in RLMs. Although this can be applied to a task where...