BUILDING Parts of this page describe what is not built yet, and each says so.
The AI layer
The AI layer is how RunningLake's agents will call an AI model for you: under the policy you set, within budgets you cap in dollars, and leaving a record of each call. A prompt can contain your data and is sent to a model provider, so this page says what exists today and which parts are only a plan. Each part that exists has its own page.
What exists today
No prompt has left RunningLake for a model provider, on any plane. The code that would make a first call is built for one task only, explaining a validation problem to the person who asked, and it is not running anywhere: it has not yet been run against a provider. Its prompt is made of a code from a closed list and RunningLake’s own sentence for that code; it carries nothing you typed and none of your data, and it has no tool. A call is held in dollars against the cap you set before it is made, and a call that would pass the cap is refused before anything is sent. The answer is kept sealed on the task for 30 days and only the person who asked can read it. The sections after this one that say “as planned” are the design for every other use of a model, and nothing in them is built. What can be set up and read today:
- The AI policy: the settings an organisation makes for AI, per scope, and how one is changed.
- AI providers: how a key you bring is entered in the console, and the connection that names it. The store that holds a key runs on the QA control plane only, until a key-management provider exists.
- AI budgets and spend: caps in dollars, who may lower or raise one, and how to read them.
The call record, as planned
The one built call (explaining a validation problem) records each attempt as one row, and so will every other call. Every call to a model will be recorded, one row for each attempt, and the record is designed to hold ids, closed words and numbers: when the call started, the kind of agent that made it and the person it acted for, the action, the model and the version of the prompt, the outcome, where it was sent, what was held for it while it ran, and what it cost in dollars once it settled.
The record is designed to name what an agent was given by reference (a kind of context, the name of a declared table or pipeline, a version, and whether it lives in the control plane or in your plane) and not to copy it. The provider's own counts of what it received and returned will appear on one call's receipt only, worded as the provider counts them. They will not appear on a list, on a budget or on the cost pages.
A prompt can contain your data, and a call sends it to a model provider. On a trial it will be sent from RunningLake's own host to RunningLake's provider account. With a key you enter in the console it will be sent from RunningLake's host to your provider, so the prompt will leave your account and pass through RunningLake on the way. A route that starts in your own plane is planned and is described when it exists.
Prompt text, as planned
Prompt text will be off by default. It will be possible to turn it on for one project, by an owner or an admin, under your organisation's AI policy, which can keep it off. Turned on, it will be kept in your own bucket for at most 30 days, each read will be audited, and the text will be fetched by a short-lived link. A trial does not offer it.
Reading calls from the command line
Two commands read a call and its receipt. The control plane serves the list: rl model calls prints the calls of the project you name that the
credential may read, and until a program records a call, that list is empty. The control plane does not serve the receipt yet, so
rl model call <id> prints nothing and, for a credential that may read calls, exits 2 with the control plane's own sentence. The two
commands as they are typed:
rl model calls -project analytics -agent pipeline -since 2026-11-01T00:00:00Z -limit 20
rl model call c_5f1e0a
rl model calls lists a project's calls, newest first, as the control plane sends them: when each started, the agent, the model, the
outcome in words, the cost and the region it was routed to, or a dash for a call that held nothing and so was never sent. -project is required (the profile may supply it), -env narrows the
list to one environment, -agent and -outcome take the words the control plane uses, -since and -until
take instants in RFC 3339, and -limit asks for 1 to 200 calls. The cost is dollars the control plane settled, or a dash: a call that has
not settled, or was refused before it was sent, prints a dash and never $0.00. Nothing is added together.
Once the control plane serves the receipt, rl model call <id> will print one call's receipt, by an id the list prints: its cost and
what settled it, where it was sent and processed, the context it was given named by reference, what was masked as counts when the control plane sends
them, and whether prompt text is stored. It never prints prompt text or the content of what a call was given, and a field the command does not know is not printed at all.
Both print the response as one JSON document with -o json, and neither has an option that could carry a key, a secret or a prompt.
They exit 0 when the read was made, even when it listed no call, 1 when the control plane refused the read or there is no such call for you, and 2 when
nothing was read. An exit 2 is not an empty list, and an empty list is only what this credential may read for what was asked: neither says that no model
was called. The rest of the command line is on
The rl command line.
What this page leaves out
It does not describe the four agents, masking of free text, how a call is priced, refused at a cap or checked against a provider's bill, how a new model release is tried beside the current one, or the planned routes that start in your own plane. Those are written when they exist.