Korelos

Author: Korelos Team

  • Korelos Early Access: What We’ve Built and What’s Coming Next

    Product

    Korelos Early Access: What We’ve Built and What’s Coming Next

    Korelos Team · 2026 4 15 · 4 min read

    Early access has been more instructive than we expected, in the best way. We shipped a platform we thought we understood and immediately found out which of our assumptions were wrong. Here’s an honest account of where we are.

    What we shipped

    The core platform is stable: agent definition via the Studio portal, REST API for agent execution, persistent memory with configurable retention, tool integrations (18 at launch, 31 now), full execution logging, and environment-based deployment (staging and production).

    Since launch, we’ve added prompt versioning with rollback, team-level access controls, webhooks for agent events, and a significantly improved tool schema editor that dropped the average time to add a custom tool from ~20 minutes to under 4.

    What we changed based on feedback

    The original memory configuration interface was too abstract. Users understood the concept but couldn’t map it to their actual use case without a lot of trial and error. We rebuilt it as a set of named presets (conversation, user profile, knowledge base) with clear descriptions and the ability to customise from there. Activation rates went up immediately.

    We also underestimated how much people would want to test agents interactively before deploying. The Studio now has a built-in chat interface for testing agents with the exact configuration they’ll run in production, including simulated tool responses.

    What’s coming

    The next major area of work is multi-agent workflows: the ability to have agents hand off to other agents, run agents in parallel, and compose more complex systems from simpler components. Early designs are in review. We expect to open this to early access users in Q3.

    We’re also working on native integrations with the major CRM platforms, better analytics for understanding how your agents are performing in aggregate, and tighter rate controls for enterprise deployments.

    A note on the waitlist

    We’re still growing gradually rather than opening fully, because we want to maintain the quality of onboarding and support as we scale. If you’re on the waitlist, you’re not forgotten. We’re working through it in order, and access will continue to open up over the coming months. If your use case is time-sensitive, reply to your waitlist confirmation email and our team will take a look.

  • How AI Agents Are Reshaping Customer Support in 2026

    Use Cases

    How AI Agents Are Reshaping Customer Support in 2026

    Korelos Team · 2026 4 8 · 5 min read

    Customer support was always going to be one of the first places AI agents landed at scale. The inputs are natural language. The tasks require judgment. The volume is high. The cost of manual handling is significant. It’s a near-perfect fit.

    A year into seeing teams deploy support agents on Korelos, a few patterns have become clear about what separates the deployments that work from the ones that don’t.

    What’s working

    The teams getting the best results are treating agents as a first-pass resolution layer, not a full replacement for human support. An agent handles the 70% of tickets that follow recognisable patterns: order status, refund requests, password resets, account questions. It escalates cleanly when it encounters something outside its scope.

    This approach consistently achieves 60-70% ticket deflection without degrading CSAT scores, which was the fear going in for most teams. When the agent escalates well, users don’t feel like they’ve been stonewalled. They feel like the agent tried and knew its limits.

    What isn’t working

    Two failure modes come up repeatedly. The first is over-scoping the agent’s initial capabilities. Trying to make one agent handle everything creates a system that handles nothing particularly well. Starting narrow and expanding beats starting broad every time.

    The second is poor escalation design. An agent that can’t gracefully hand off to a human, complete with the context of what it tried and why it failed, creates a worse experience than no agent at all. Escalation is a feature, not a fallback.

    The tools that matter most

    Across all the support agent deployments we’ve seen, there are four tool integrations that show up in every high-performing setup:

    • Order/account lookup (read access to your core data)
    • Ticket creation (for creating support records and escalating)
    • Knowledge base search (for policy and product questions)
    • Action execution (refunds, cancellations, plan changes — with appropriate guardrails)

    The last one is where most teams are cautious, and reasonably so. Giving an agent write access to take actions on behalf of users requires careful scoping and robust logging. But it’s also where the biggest resolution rate gains come from.

    Getting started

    If you’re considering a support agent deployment, the fastest path to something useful is to pull your last 500 tickets, categorise them by type, and identify the three highest-volume categories that follow a predictable pattern. Build an agent that handles exactly those three categories well. Ship it. Measure. Expand from there.

    The teams that try to solve every ticket type in the first version rarely ship. The teams that start with a narrow scope almost always do.

  • Memory in AI Agents: Why It Matters More Than You Think

    Engineering

    Memory in AI Agents: Why It Matters More Than You Think

    Korelos Team · 2026 3 27 · 7 min read

    The demos always look the same. A user types a question. The agent answers. Everyone nods. What the demos don’t show is what happens in the second conversation, or the fiftieth, when the agent has no idea who it’s talking to or what happened before.

    Memory is one of those things that seems optional until you try to ship something real. Then it becomes the problem you can’t ignore.

    Why context degrades without memory

    A language model’s context window is a finite resource. In a long conversation, you either pay to include more history (expensive, and eventually impossible) or you truncate (and lose information the agent needs). Neither is a satisfying answer.

    The deeper issue is that even within a conversation, different kinds of information need to be managed differently. Facts the user told you in session one (“I’m on the Pro plan”) have different lifetimes than temporary working state (“I’m currently helping them with order #4821”).

    Three layers of memory

    The way we think about it at Korelos, there are three distinct layers:

    • Session memory: The current conversation. Active while the session is open, discarded after. Used for tracking intermediate state and the immediate context of what’s being discussed.
    • User memory: Persistent facts about a specific user. Their preferences, their plan tier, their history with your product. Persists across sessions. Scoped to the user identifier you provide.
    • Global memory: Shared context that applies to all interactions. Your product FAQ. Business rules. Things that don’t change per-user but that every conversation might need.

    How Korelos handles this

    When you deploy an agent on Korelos, you configure a memory policy as part of the agent definition. You decide which layers are active, what the retention window is, and what gets summarised vs. stored verbatim. The platform handles the mechanics: retrieving relevant context at the start of each turn, updating user memory when the agent extracts persistent facts, and purging session state when conversations close.

    None of this requires you to write any memory management code. It’s part of the infrastructure that Korelos handles by default.

    The thing most people get wrong

    The most common mistake is treating memory as a retrieval problem and ignoring the write side. Getting the right context into the model matters, but so does deciding what to write to long-term memory in the first place. If you store everything, retrieval becomes noisy. If you store nothing, context is lost.

    Our agents use a lightweight extraction step at the end of each session to decide what, if anything, is worth persisting. You can configure what types of facts to extract or write your own extraction logic. Most teams start with the defaults and tune from there.

  • AI Agents vs. Traditional Automation: What’s Actually Different?

    Education

    AI Agents vs. Traditional Automation: What’s Actually Different?

    Korelos Team · 2026 3 18 · 6 min read

    When people hear “AI agent,” they sometimes think of a smarter chatbot or a fancier automation script. That framing undersells what’s actually new here and leads to poor decisions about when to use each approach. Let’s draw the line clearly.

    Traditional automation: rules all the way down

    RPA tools and rule-based bots work by executing a deterministic set of instructions. If condition A, do X. If condition B, do Y. This works extremely well for predictable, high-volume tasks with little variation. Processing invoices that always arrive in the same format. Filling out forms. Extracting data from structured documents.

    The brittleness comes when inputs vary. A rule-based system that handles invoices from Vendor A breaks the moment Vendor B sends a slightly different layout. Someone has to update the rules. The maintenance overhead compounds over time.

    AI agents: reasoning over rules

    An AI agent doesn’t execute a predefined path. It reads the situation, decides what to do, calls whatever tools are appropriate, and adapts when things don’t go as expected. The same agent that handles a straightforward refund request can also handle a nuanced complaint that requires judgment — without you having to write a rule for every possible case.

    This shift from rules to reasoning is what makes agents genuinely different, not just incrementally better.

    The trade-offs are real

    Agents are not strictly better than traditional automation. They’re better at different things.

    • Predictability: Rule-based systems are deterministic. Agents are probabilistic. If you need 100% consistent output on a structured task, traditional automation often wins.
    • Cost: Each agent run involves a model call. For very high-volume, simple tasks, RPA is cheaper.
    • Auditability: It’s easier to explain exactly why an RPA workflow did something. Agent reasoning can be logged but requires more work to audit.

    Where agents genuinely win

    The cases where agents provide clear, outsized value are tasks that involve:

    • Natural language input from users
    • Decisions that require judgment rather than lookups
    • Multiple tools or data sources that need to be combined
    • Workflows that vary significantly between instances
    • Tasks where the cost of a missed edge case is high

    Customer support, research workflows, content operations, and internal tooling are all areas where agents consistently outperform rule-based approaches because the variance in inputs is simply too high for rules to handle cleanly.

    The practical answer

    Most mature systems end up using both. Rule-based automation for the predictable, high-frequency tasks where consistency matters. Agents for the parts of the workflow that require understanding and judgment. Knowing which is which is the skill worth developing.

  • Your First AI Agent in Under 5 Minutes

    Tutorial

    Your First AI Agent in Under 5 Minutes

    Korelos Team · 2026 3 5 · 4 min read

    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.

  • Why We Built Korelos: The Infrastructure Problem No One Talks About

    Company

    Why We Built Korelos: The Infrastructure Problem No One Talks About

    Korelos Team · 2026 2 20 · 5 min read

    In mid 2025, we spent four months watching the same thing happen across different teams. A product manager would have a great idea for an AI agent. Engineers would get excited. Then, about two weeks in, the enthusiasm would quietly fade. Not because the idea was bad. Because building agents is genuinely hard in ways that aren’t obvious from the outside.

    The hidden work before the real work

    Before you can even test whether your agent idea works, you have to build infrastructure that has nothing to do with the agent itself. You need a way to manage conversation memory across sessions. You need to handle tool calls reliably, with retries and timeouts. You need observability so you can debug why an agent went wrong. You need to version your prompts. You need auth, rate limiting, and a deployment model.

    By the time most teams finish that scaffolding, they’ve spent weeks and still haven’t written a single line of actual agent logic.

    We saw this happen too many times

    One team spent six weeks building an orchestration layer before their first agent went live. Another team rebuilt the same memory management code three times across different projects because there was no shared infrastructure. A solo developer gave up entirely because the setup overhead made iteration too slow to be worth it.

    The problem wasn’t lack of skill. It was a missing layer of abstraction.

    What Korelos is, and why it exists

    Korelos is the infrastructure layer that lets you skip straight to the agent logic. You define your agent in plain English, connect your tools via our integrations library, and deploy with a single API call. Memory, retries, observability, versioning, all of it is handled for you.

    We built it because we kept running into teams who had great agent ideas and were being blocked by plumbing. That felt like a solvable problem.

    The best infrastructure is the kind you don’t have to think about. Korelos is our attempt at that for AI agents.

    What’s next

    We’re in early access right now, and the feedback has shaped almost everything about how the platform works today. If you’re building agents and spending more time on infrastructure than on the actual problem you’re solving, we’d love to show you what Korelos can do.

  • What Six Months of Building AI Agents Taught Us About Tool Use

    Use Cases

    What Six Months of Building AI Agents Taught Us About Tool Use

    Waleed Ghaffar, Founder & CEO · 2026-02-14 · 5 min read

    Korelos has been in private early access for six months. In that time we’ve worked closely with about a dozen teams across customer support, internal operations automation, and research. The common thread across every successful deployment hasn’t been the model or the prompt. It’s been how the team thought about tools.

    Lesson 1: Most teams ship with too many tools

    The instinct, when you sit down to build an agent, is to expose every API your company has. “The agent can do anything.” In practice, the more tools you expose, the worse the agent’s planning gets. We saw one team with twenty-eight tools whose agent was getting confused about which to use, even on simple requests. They cut it to seven and accuracy jumped immediately.

    Start small. Add tools when you can point at a specific failure that the missing tool would have prevented. Not before.

    Lesson 2: Tool descriptions are prompt engineering

    The descriptions you write for each tool are not documentation. They are part of the agent’s prompt, and the model is going to make routing decisions based on them. A tool described as “Looks up order status” will be reached for very differently than one described as “Retrieves the current shipping status, last carrier event, and delivery ETA for an existing order. Use this when the customer is asking where their package is.”

    The teams that took this seriously got measurably better routing. The teams that didn’t kept blaming the model.

    Lesson 3: Tool inputs should look like commands, not API requests

    Models are good at producing natural-sounding intent. They are bad at producing the kind of nested, optional, type-strict JSON that REST APIs from 2018 expect. The teams that got the best results designed tool input schemas that read like how a human would describe the action: find_order(query) instead of orders.search({"filter":{"order_id":{"eq":...}}}).

    If your real API needs the second shape, write a thin adapter. The agent never sees it.

    Lesson 4: Outputs need a budget

    Tools that return five-megabyte JSON blobs will eat your context window. Every tool needs to either return a small, summarized result, or return a handle that the agent can choose to expand. The default of “return everything the API returned” is the single most common reason agents fall over after a few turns.

    The single biggest predictor of agent success isn’t the model. It’s whether the team treated tool design as a first-class problem.

    What we’re doing about it

    Most of what’s gone into the Korelos tool layer over the last six months has been about making these patterns the easy default. Tool schemas are validated against best practices when you create them. Output sizes are budgeted automatically. Tool descriptions are linted for the things we’ve seen go wrong in production. None of this is glamorous, and none of it is what an agent demo on day one cares about. All of it is the difference between an agent that works for a week and one that’s still working in six months.

    We’re going to keep writing about what we learn. If you’re an early-access partner, expect this kind of post to be the norm. If you’re not yet, the waitlist is open.

  • Function Calls vs. Stateful Agents: A Practical Comparison

    Tutorial

    Function Calls vs. Stateful Agents: A Practical Comparison

    Hussein Aalee, CTO · 2026-02-05 · 7 min read

    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.

  • Why We’re Building Korelos in Pakistan

    Company

    Why We’re Building Korelos in Pakistan

    Waleed Ghaffar, Founder & CEO · 2026-01-22 · 5 min read

    Almost every AI infrastructure company you’ve heard of was started in San Francisco. The default assumption when someone says “we’re building an AI startup” is that you’re somewhere within a forty-minute drive of the Caltrain. We’re not. Korelos is being built in Islamabad, and I want to be honest about why that’s a deliberate choice.

    The talent argument

    Pakistan graduates more software engineers per year than most people realize, and the ones at the top of the curve compete directly with anyone in the world. We’ve been able to assemble a small founding team without compromising on technical depth. The cost structure means we can afford to take longer to get the architecture right, instead of shipping the first thing that compiles to chase a runway clock.

    The proximity-to-customers argument

    The honest counter is: most early enterprise AI buyers are in the US and Europe. We don’t pretend otherwise. What we’ve found is that asynchronous-first communication, written specs, and recorded demos cover ninety percent of the early-customer relationship anyway. The other ten percent is travel, and travel is solvable.

    The local context argument

    There’s a real advantage to building infrastructure for AI agents from somewhere that doesn’t already assume the answers. The teams in San Francisco are converging on a small number of architectural patterns because they all read the same blog posts and go to the same dinners. We get to look at the same problems with a slightly different starting context, and that’s produced ideas in the codebase that I’m genuinely proud of.

    The honest tradeoffs

    Time zones are real. Banking and payment infrastructure for international customers is harder than it should be. The investor mental model for “AI infra startup” comes pre-loaded with a Bay Area address, and we’ve had to be patient about explaining that this isn’t a downside. We’ve also had to be deliberate about hiring — there are domains (e.g. enterprise distribution) where US-based co-leads will eventually matter, and we’re planning for that.

    None of these tradeoffs are unique to Pakistan. They’re the tradeoffs of building anywhere outside the default. The difference is that we get to make them on purpose.

    Where we’re going

    We’re a small team right now: a founding pair (myself and our CTO Hussein Aalee), a roadmap pointed at developer beta in mid 2027, and an early-access waitlist that’s growing faster than we expected. We’re going to keep being honest about where we are, what we’re building, and how we got here. I think that’s the right way to do this.

    If you’re building agents and want to be part of the early-access cohort, the waitlist is open. We read every signup.

  • The Three-Layer Stack Every Production AI Agent Needs

    Engineering

    The Three-Layer Stack Every Production AI Agent Needs

    Hussein Aalee, CTO · 2026-01-08 · 6 min read

    If you’ve shipped more than one AI agent to production, you’ve probably noticed something: the architecture diagrams on day one and day ninety look almost nothing alike. Day one is a single endpoint that wraps a model call. Day ninety is a sprawl of retry loops, memory stores, tool wrappers, observability hooks, and prompt-versioning hacks duct-taped together by whoever was on call at 3 a.m.

    After eighteen months of watching teams iterate on this exact arc, we’ve come to believe the same three-layer pattern always emerges. The teams that get there fast win. The teams that get there slow burn out and blame the model.

    Layer 1: The agent runtime

    This is the layer that takes a goal and a context, decides what to do next, and either calls a tool or produces a response. It is not just a model call. It’s a control loop with budgets (tokens, tool calls, wall-clock time), step-level fallbacks, and structured outputs.

    Common mistake: pushing all the logic into the prompt. The prompt is one input to this layer, not the layer itself. Anything stateful, anything that needs to be debugged, anything that needs metrics — that belongs in the runtime, not the prompt.

    Layer 2: The tool layer

    Tools are how the agent affects the outside world. The hard parts here are not the tools themselves; the hard parts are the contracts. Each tool needs a schema the model can target accurately, an executor that handles transient failures cleanly, and a result format that’s compact enough to fit back into the next agent step without blowing the context window.

    We’ve seen teams build their tool layer as a thin wrapper around their existing API surface. That works for two weeks. Then they discover that the schemas LLMs work well with are not the schemas humans wrote for REST endpoints in 2018, and they have to redo the whole thing.

    Layer 3: Memory

    Memory is where production agents diverge from demos most dramatically. A demo can fit everything in the prompt. A production agent supporting thousands of conversations cannot.

    The memory layer needs at least three scopes: per-session (this conversation), per-user (everything we know about this person), and global (organization-level facts). Each scope has a different lifetime, different retrieval strategy, and different write semantics. Treating them as one big bucket is the most common architectural mistake we see.

    If your memory layer is “stuff the last 20 messages into the prompt,” you have a demo, not a system. The day a customer comes back after a week and asks “remember when we…” is the day you find out.

    Why we built Korelos around this

    Every agent we’ve helped teams ship needed all three layers. Every team that tried to skip one paid for it later. Korelos exists because we got tired of watching smart engineers rebuild the same scaffolding for the fifth time. The runtime, tool layer, and memory layer are the platform — what you bring is the goal.