One of the things we care most about at Korelos is time-to-first-working-agent. If you have to spend an afternoon setting things up before seeing anything useful, we haven’t done our job. Here’s how fast the real experience is.

Step 1: Create your agent

Log into the Korelos Studio portal and click New Agent. Give it a name and write your system prompt in plain English. This is where you define what the agent does, how it responds, and what boundaries it operates within.

You are a customer support agent for Acme Corp. 
You help users with billing questions, order status, and returns.
Always be concise. If you can't resolve something, escalate to a human.
When looking up orders, always verify the user's email first.

That’s it. No YAML, no schemas, no configuration files.

Step 2: Connect your tools

Tools are what give an agent the ability to do things beyond answering questions. In the Studio portal, you can connect tools from our library (including database lookups, HTTP requests, Slack, email, and more) or define custom tools with a simple JSON schema.

For our support agent, we’d add an order_lookup tool and a create_refund tool. Each tool has a name, a description (which the model uses to decide when to call it), and a schema for the parameters.

Step 3: Deploy and call the API

Click Deploy. Korelos generates an endpoint for your agent. From that point on, you interact with it over a standard REST API:

POST /v1/agents/{agent_id}/run
{
  "session_id": "user_12345",
  "message": "Hi, I need help tracking my order #4821"
}

The platform handles the conversation state, tool execution, retries, and logging. Your application just sends messages and receives responses.

What you get for free

• Persistent memory across sessions (scoped per user or globally)
• Automatic retry logic for tool failures
• Full execution logs in the Studio dashboard
• Versioned deployments so you can roll back instantly
• Rate limiting and auth built in

None of that required any extra configuration. It’s there by default because those are the things every production agent needs.

One of the most common questions we get from engineers evaluating Korelos is some version of: “Why do I need an agent runtime? I can just call function_call on the model and handle the rest myself.”

It’s a fair question. For about thirty percent of use cases, the answer is “you’re right, you don’t.” For the other seventy percent, what looks like a single function call on day one becomes a fragile reimplementation of an agent runtime by month three. This post is about how to tell which side of that line you’re on.

What a function call gives you

The model returns a structured request: “call get_order_status with order_id=42.” You execute it, you put the result back in the conversation, you call the model again. That’s it. One round trip per tool use, fully under your control, easy to debug.

For single-step, single-tool tasks — “look up this order, summarize it” — this is genuinely all you need. Don’t add an agent runtime if you don’t need one.

Where it breaks down

The cracks start to appear when any of the following become true:

• Multi-step planning. The agent has to decide what to do next based on what just happened, possibly with a goal that takes 4–10 tool calls to achieve.
• Conditional branching. “If the order status is shipped, do X; if it’s pending, do Y.” Encoding this in code makes the model’s planning behavior brittle.
• Memory across turns. The user mentioned their preferences yesterday. You need to surface them today without re-asking.
• Error recovery. The tool returned a 503. The agent needs to retry, or back off, or pick a different tool, or ask the user to clarify.
• Cost and time budgets. “Don’t spend more than $0.20 or 30 seconds on this conversation.”

Every team I’ve seen try to bolt these onto a raw function-call loop ends up writing the same five hundred lines of orchestration code. It’s not that hard, but it’s not that easy either, and it’s the same code in every project.

What a stateful agent gives you

An agent runtime makes the control loop the primitive. You give it a goal, tools, and constraints; it does the rest. In Korelos, that looks like:

const run = await korelos.runs.create({
  agent_id: 'support-agent-v1',
  input: 'Where is my order #42 and why was the last refund delayed?',
  budgets: { steps: 8, tokens: 4000, ms: 30000 },
});

Behind that one call: planning, tool dispatch, retries on transient failures, memory retrieval, structured output, observability traces, and budget enforcement. None of that is in your code, because none of it is logic that’s specific to your problem.

The decision rule

If your interaction is one round trip, use a function call. If it’s a conversation or a workflow with conditional steps, use an agent runtime. The cost of being wrong in the first direction is “a little bit of overhead.” The cost of being wrong in the second direction is six weeks of yak-shaving.

The right primitive at the right layer of abstraction saves more time than any single feature.

That’s the bet behind Korelos: that more teams need an agent runtime than realize it, and that the ones who try to skip it end up rebuilding it badly.