kortecxdocs

Limits

Every limit on what Kortecx does today, and the defaults it starts from. Read it before you rely on Kortecx for anything that matters.

This page lists the limits on what Kortecx does today, and the defaults it starts from. What follows is the whole list. Read it before you rely on Kortecx for anything that matters.

The promise the limits surround

One item here is a promise rather than a limit, and it is the reason the rest is worth reading: work is done exactly once, and a run is safe to re-run. If a run fails partway, a retry picks up where it stopped, and work that already reached the outside world — a message sent, a ticket filed, a row written — does not happen a second time. That property is real, you can observe it yourself, and it is what we stand behind. Almost everything else on this page is a boundary around it. See what you can rely on.

Scale and capacity

Nothing manages capacity for you. Capacity does not grow under load and does not stand itself down when nothing is running. Throughput has a ceiling, and a queue in front of it.

Work does not spread across machines. Everything a deployment runs happens in one place. Putting more hardware beside it does not add throughput, and there is no way to split one job across several machines.

Nothing separates one team's work from another's inside the same deployment. Connections, secrets, datasets, apps and branches are reachable by everyone who can reach that deployment. Treat the deployment as the boundary, and keep separate what has to stay separate.

Access and credentials

Access is closed until you open it. Nothing is reachable, and no run may touch anything, until you grant it. That is the default in both directions and it is deliberate.

Your credential is you. The token you sign in with is a bearer credential: anything holding it can do what you can do. Keep it out of source control.

A credential in a browser page is visible to that page. Nothing persists a token beyond memory, which is not the same as safe. If a key reaches front-end JavaScript, treat it as published — call from your own back end instead.

Not every capability is on in every deployment

Durable memory — an agent remembering a fact across separate runs — and datasets — the document corpora agents search to ground an answer — are not switched on everywhere.

Where one is not available, the call says so rather than returning an empty result. That distinction is the point: you will never mistake off for nothing found. Check before you design around either.

See Memory and Datasets.

An App's front end is not published anywhere

An App can carry a small web front end. Read this section carefully, because it is the most misread capability we ship.

  • It is not published. There is no public address for it, and nothing outside the machine running it can open it.
  • It is single-user. There is no mechanism here for making an App's front end reachable by other people.
  • Running someone else's App front end runs their code. It installs its own JavaScript dependencies and runs with the permissions of whoever started it. Treat that exactly as you would treat running any code a stranger sent you, because that is what it is.

Sharing an app covers what does travel between people, and what does not.

What an exported App proves — and what it does not

You can package an agent as a portable bundle and hand it to someone:

On import, the bundle records where it came from.

That is a lineage hint, not a signature. There is no signing here. It tells you what an App claims to have been derived from. It does not prove who authored it, does not prove the bytes were not altered, and does not make the sender trustworthy. Read a bundle before you run it.

What the design does give you: an App carries no authority. Importing one grants it nothing. Every capability it wants is re-checked against your grants at run time, and connections and secrets never travel inside a bundle — you re-register your own by name. A hostile App still cannot silently acquire powers you did not give it. See Sharing an app.

Things that do not exist

Stated plainly, because their absence is easy to assume away.

  • One app cannot call another app. There is no invocation, chaining, or message-passing between two Apps at any layer. Agents coordinate inside one app — the steps of a workflow file's graph.

    If your design needs App A to trigger App B, the runtime has no answer for you today. See Workflows.

  • No export into your own monitoring tools. What you get is what the console and the CLI show you. There is no metrics feed to point your own stack at.

  • No service commitment and no compliance certification. Nobody is on call for you, nothing is promised about availability, and no external audit or certification has been performed.

Observability and cost are display-only

Everything in this section is audit and display material. None of it decides anything about a run.

  • Telemetry: a run's steps, how each one ended, and its token counts.
  • Cost: a spend estimate at list rates for runs on your own model key, with a daily cap an owner or admin can set — not a bill. It is built from what the runtime can measure, never from everything a provider will actually charge you.
  • No alerts. A failed run reads as failed in its run history; nothing pages you.
  • Audit record: the run lifecycle, join keys only — never payloads, never secrets.

More in Observability and Cost.

What we do stand behind

A complete list of limits is only useful next to a complete list of what holds.

  • Work is done exactly once, and re-running is safe. A step that reached the outside world is not repeated by a retry, and a run started again with the same idempotency key resumes instead of starting over.
  • The model proposes; the runtime enforces. A model may suggest any tool call it likes. Whether it happens is decided against what you granted that run — the exact tool, the exact version, the exact reach — by exact match, never by a similarity score.
  • Anything irreversible waits for a person, wherever you say it must. See Approvals.
  • Who you are is derived, never claimed. No client, SDK or model asserts an identity or constructs a run's identity; it comes from your credential.
  • Closed by default. Access, and what a run may reach, both start shut.

The four guarantees are stated in full, with what they do not cover, in what you can rely on.

If you find something true about the runtime that is missing here, that is a bug in this page, and we want to hear about it.