If you're building an AI product, you've probably climbed a ladder without noticing it had rungs.
You started with a prompt: send text, get text back. Then you wrapped it in an application: retrieve some context, format an answer, maybe call an API. Then you gave it tools and let it decide what to call and when. Suddenly, it's an agent. Each rung felt like a natural next step, and a good framework carried you up all three without much friction.
The fourth rung is where orchestration starts: long-running tasks; agents that develop a personality and get to know you over time; specialist agents shared across people or departments; groups of agents that work together; and research fan-outs that consolidate into a shared “brain” of company knowledge. You also need rules about who can see what and whose voice an assistant speaks in. Now you're building an agentic engine rather than a single agent. At this stage, it can pay to ask a question the first three rungs never did: who owns the loop?
The challenges that require control of the loop
Underneath the product features, a tool-using agent follows a small repeated cycle: assemble context, call a model, handle its reply or tool requests, add the results back to context, and continue until there is a final response. The agent harness is the software that runs that cycle around the model: it manages the conversation, context, tools and streaming.
You do not need to build a harness from scratch to reach the first three rungs. Established frameworks already provide this machinery, and using one is usually the sensible choice while the product is still serving one person or one team. For a practical example of that stage, see how we built an agent to do our marketing.
The trouble starts as you scale up and meet questions the framework never made room for. This is no longer only about what the prompt should say; that remains configuration. The harder questions are: who is responsible for this tool call, so you can bill, secure and audit it correctly? Which parts of the company’s knowledge may this agent use for this particular person, right now?
Those are not decisions a prompt alone can enforce. Some of those decisions belong before a run starts: what this agent may know, which persona it speaks in and which tools it may request. Others belong at the action boundary: whether this exact run, acting for this exact identity, may perform this exact tool call now, within budget and with the right approval.
A framework can support those decisions when it gives you safe places to add the checks. Without them, you can still put proxies and policy services around it. That is where we first looked.
We tried this approach when we built the first version of OpenCrane. Our initial architecture sandboxed the agent harness OpenClaw in a cluster alongside central company assets and network-enforced role-based access control. That is where the name OpenCrane came from. The architecture produced a strong prototype and showed that the concept could work, but it did not pass the deeper QA required for production. Because OpenClaw still owned the lifecycle state, the layers around it became technical debt. As we added stricter controls for approvals, memory and tool use, it became difficult to preserve the exact relationship between a run, its proposed action, the approval and the returned result. Those links are essential when you need to control agents across an organisation.
OpenCrane's purpose is to make agentic AI manageable across an organisation, not just for one person. The mismatch between the two architectures led us to take control of our own agent loop.
How one Agent Run works
A conversation with an agent feels like one continuous exchange: you start a thread on a topic and the agent gets to work. Underneath, the conversation is a sequence of Agent Runs. A kick-off or follow-up message starts a run. Within it, the runtime may call the model several times and pause for a tool result, feedback or approval. A paused run resumes from the same state. It ends only when it returns a final response or is cancelled; the next user message then starts the next run.
The runtime is the program that owns each run. It prepares the inputs, calls a model provider, receives the streamed response, records what happened and moves the run to its next step. The model tends to receive most of the attention, but it is only one part of that process. Its role is deliberately narrow: it receives compiled context and may return text, a request for feedback or proposed tool calls. It does not own the conversation, execute a tool or decide its own permissions. The runtime coordinates those boundaries.
Implementations differ, but a new message generally starts the following loop inside the runtime:
Context. Before any model call, the runtime assembles the run's inputs: the message and goal, the agent persona, conversation history, relevant files and earlier tool results, the memory it may use, and the tools it is allowed to request. In OpenCrane's run authority, those inputs become one immutable
RunInputSnapshot, recorded with a digest. The prompt compiler then turns that sealed snapshot into the literal context sent to the model. The important work has already started before the model sees a prompt.Execute. The agent runtime uses that compiled context to make one model request and streams the response as it arrives. The model may produce text, request feedback, or propose one or more tool calls, such as reading a file, querying a database or sending an email.
Evaluate. The runtime looks at what came back from the model and chooses the allowed next path. Did the model return a final answer, ask for feedback, or propose one or more tool calls? That is what “evaluate” means here: classify the response and apply the matching lifecycle rule. It is deterministic routing, not a judgement about whether the answer is good:
3.1. Continue with updated context. A proposed tool call becomes a bounded candidate for the control plane. The runtime does not execute the action itself. Once the authorised action returns a result, that result is added to the conversation in the order the model requested it and becomes context for the next round.
3.2. Elicit a decision. A request for feedback pauses the run until a person responds. A tool that needs approval pauses in the same way and routes the decision to the accountable person. When the input arrives, the same run can resume from its recorded state.
3.3. Return a response to the user. If the model has produced a final answer and proposed no further tool calls, the run completes and returns that response.
The loop can repeat several times within one run. A pause preserves the exact state needed to continue. Only a final response or cancellation ends the run; after a final response is streamed to the user, the next message starts another.
Extending the loop in action
Owning the loop means deciding what happens at each stage, rather than accepting the stages a framework exposes. These are some of the controls we are applying or exploring in OpenCrane:
- Approve MCP tools without restarting the task. When an agent needs access to a new tool through the Model Context Protocol (MCP), pause the run and send the request directly to the IT administrator who owns that decision. Once IT approves it, the same run resumes with its context intact. The same pattern can route a file request, purchase or other decision to the accountable manager or budget owner.
- Auto-model on steroids. Re-evaluate which model is the cheapest one that is still right for the next round or sub-loop. A routine retrieval step and a difficult judgement do not have to use the same model simply because they belong to one run. OpenCrane already has a version of this set around the loop, but by owning the loop we can now experiment with this in-flight.
- Steer work while it is running. Redirect an agent between rounds as soon as its reasoning heads in the wrong direction. The useful work and context remain in the run, so the person does not have to wait for a final answer or restart the conversation.
- Create governed sub-agents and sidecars. Let an agent create a narrower specialist for one task, with less authority than its parent and no manual re-provisioning. A separate sidecar session can research, monitor or check the work, then return a bounded result to the main run or a shared conversation. More like an agent dispatch, than a subagent, experience.
- Protect context across organisational boundaries. Let an agent reason over company or personal files while callers and sub-agents receive only the information they are allowed to see. We are experimenting with partly redacted memory sidecars that keep those access boundaries attached as context moves between runs.
Approval flows can be built around an existing harness, but keeping them inside the run makes the pause, decision and continuation part of one record. Model routing, sidecar sessions and protected memory are more experimental and still need work before they become everyday OpenCrane features.
The own-runtime refactor exposes two places for this control. Identity, persona, available knowledge and allowed tools are fixed when a run starts. Permissions, budget limits and approval requirements are checked again when the model proposes an action. The runtime protocol authority keeps the proposed action, decision and returned result attached to the same run.
Who should skip this
Owning the loop is not free. You inherit work that a good framework previously absorbed: reliability engineering, retries, cancellation, context management and recovery from model outages. The reason to take control is a specific product decision that the frameworks give you no safe place to make.
The power of agentic engineering puts owning such a loop within everyone's grasp. Go for it if you can see some value in it, or fork ours!
Building your own product? Our AI adoption engineering team can also help you navigate what the trade-offs and cleanest paths are.
