Reliability

KeenAgents is designed so that no administrative action is silently lost. Every change you make either applies completely and is confirmed, or is refused with a clear error message — never half-applied, never quietly dropped. Every successful administrative action is also recorded in a permanent audit trail, so "who changed what, and when" always has an answer.

When part of the platform is interrupted, KeenAgents degrades gracefully and heals itself. The affected capability pauses and refuses new requests with a clear error instead of answering wrongly or hanging; everything else keeps working. Recovery is automatic — once the interruption clears, the paused capability resumes on its own, with no restart and no administrator intervention. Events raised in the meantime — audit lines, log lines — are held safely and recorded once the platform resumes, so maintenance does not lose events.

No silent loss

An admin action either takes full effect and is confirmed, or you see an error explaining the refusal. A refused action can be retried; a silently dropped one could never be — which is why the platform always chooses the loud refusal.

Permanent audit trail

Every administrative action is recorded with the requester's email, user id and role, what was changed, and the new value. The audit trail cannot be switched off by anyone — an audit trail that can be disabled is not an audit trail.

Graceful pauses

An interrupted capability pauses cleanly: requests to it are refused with an error rather than served with stale or partial data, and the rest of your organization keeps working. A clear refusal is diagnosable; a wrong answer is not.

Automatic recovery

A paused capability resumes by itself the moment the interruption clears — no restart, no support ticket, no admin steps. Detection is deliberately steady in both directions, so a brief blip does not cause visible flip-flopping.

Maintenance-safe events

Audit and log events raised while recording is paused — during maintenance, restarts or heavy load — are held and written once recording resumes, instead of being lost. You do not need to schedule around it.

Stable sessions

Maintenance and restarts never sign users out and never invalidate issued tokens. Signing material is only ever rotated by an explicit administrative decision, because rotation invalidates every outstanding token — that is a choice, never a side effect.

• The Logs page groups the platform's own recording into five system channels — action, error, warning, info and debug. On a fresh organization action and error are on; warning, info and debug are off. Runtime lines from your agents and scripts are not a channel here — they are captured per space or per agent as Log Records (see Logs & Monitoring).
• System action (the audit trail) and system error are permanently engaged — their switches are locked in the console (Permanently engaged) and an attempt to flip them through the API is refused. The record of admin actions and errors must survive any configuration mistake.
• Toggling any channel is itself an audited action: the platform records who flipped it (email, user id, role), which setting, and the new value — configuration changes leave the same trail as everything else.
• Lines arriving on a switched-off channel are dropped for good, not queued: turning a channel on affects only lines emitted afterwards. Off means off — nothing is secretly retained against your configuration.
• Each channel keeps one file per day, listed newest first and retained for 30 days, so you always know exactly how far back you can look.
• Opening a file shows its last 40 records, newest first. It is a triage view for answering "what just happened", deliberately kept small and fast — not a full-file export.
• Viewing logs requires the logs permission on your role; toggling a channel additionally requires its write grant. Reading and reconfiguring the record are separate privileges on purpose.
• Your agents' runtime lines are separate from the audit trail: you turn them on per space or per agent as Log Records (Logs & Monitoring). Their stored lines are kept for 30 days, and the live stream is ephemeral — a promise about your audit trail is not a promise about a partner's live view.

1. Something a capability depends on becomes unavailable. Detection is deliberately steady rather than jumpy, so expect up to about a minute before the platform reacts; during that window a request may fail with an error — it is always safe to retry.
2. The affected capability pauses: its pages and API calls refuse with a clear error, while the rest of your organization — and every signed-in session — is unaffected.
3. The audit trail and error record keep recording throughout. If recording itself is what paused, events raised in the meantime are held and written once it resumes.
4. The interruption clears and the capability resumes automatically, typically within seconds. Nothing needs to be restarted, re-enabled or reconfigured afterwards.

KeenAgents is built for guaranteed completion over raw speed. Once a task is accepted it always runs to an exit — it is never abandoned mid-run. To protect that, each step of a run has a size budget: a request that fits is carried through to the end, and one that cannot fit is refused clearly rather than silently truncated or left to loop. The numbers below are defaults — they can be raised per deployment to match a workload.

A node execution

Has a fixed size budget per step. Past it the node fails and takes its Error edge (if wired) instead of destabilizing the run — it means the step tried to hold too much at once. Split the work, or keep less in the step (a fetched response alone may be up to 10 MB — see below).

The dictionary / the session

About 1.5 MB each. Past it the write is rejected — the shared working data is for coordination values, not bulk payloads. Keep only what the flow needs to pass along; fetch large data when you need it rather than parking it here.

One stored conversation turn

Up to 8 MB per stored agent message or reply. Past it that single entry is rejected — it means one turn is carrying too much; trim the oversized content.

A single message on the wire

8 MB. Past it the message is refused immediately — never retried. A turn this large can never be delivered, so the platform fails fast rather than looping forever. It means the prompt plus the context you send is too big; reduce it.

A fetched HTTP response

Up to 10 MB (the buffer system/http reads a response into). Past it the fetch fails — it means the response is bigger than a script can take in one call; page the data or narrow the request.

Under load

The platform admits new work as capacity allows; a request that arrives at a saturated moment waits and retries until it is taken. A "please retry" under load is the guarantee working — not a failure.

Nothing accepted is ever dropped. Work is spread across the platform; when part of it nears its limit it takes no new work and the rest absorbs the load. The only thing that can be refused is the very first acceptance of a brand-new request at peak, and the client simply retries — a task that has already started is never abandoned; the work lands the moment capacity frees. The platform is deliberately tuned to guarantee the task finishes, not to be the fastest.

Scaling. A sandbox is a build-and-test environment and is not sized for real traffic; production is sized to your expected load, and more capacity means fewer retries under bursts. Even fully scaled, if everything is momentarily saturated new requests retry rather than fail — peak load degrades into a short wait, never a lost task.

When capacity is momentarily full. A run's working data is kept for as long as the run is alive and reclaimed shortly after it ends. If enough runs are active at once to exhaust that capacity, the platform refuses a brand-new run rather than disturb a live one — no running task ever loses its data. That refusal is retryable: as runs finish, room frees and the retry lands. Saturation shows up as a new request being asked to wait, never as a running task being corrupted or dropped.

• A paused capability is not broken. It will resume on its own — there is nothing for you to fix, and restarting things yourself is never required.
• After maintenance, KeenAgents verifies everything before accepting work: if any startup check fails, the platform stays down and reports the reason instead of coming up half-configured. A platform that starts half-configured fails unpredictably later — refusing to start is the safer promise.
• The audit trail never goes quiet: no configuration change, outage or maintenance window can silence the action and error records.
• The held-events promise covers maintenance, restarts and overload. Its one honest limit: an abrupt machine-level crash can at worst cost the very last moments of the record — planned maintenance loses nothing.
• Restarts and upgrades never invalidate sessions or tokens. Only an explicit rotation of signing material does — and that is always a deliberate administrative act, never automatic.