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 recording into channels and levels: a System channel with action, error, warning, info and debug, and a Log channel with error, warning, info and debug. On a fresh organization, system action, system error and log error are on; everything else is off.
• System action (the audit trail) and system error are permanently engaged — trying to switch them off is refused with This log is permanently engaged. 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.

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

About 40 MB (≈30 MB for your logic plus ≈10 MB for the buffer a system/http response reads into). 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 in memory at once. Split the work, or keep less in memory.

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.

Concurrent work per instance

About 16 node executions at once (default). Near its budget an instance stops taking new work; a request with no free instance waits and retries until one takes it. A "please retry" under load is the guarantee working — not a failure.

Under load — nothing accepted is ever dropped. Instances handle work as a group and spread it between them. When one nears its budget (around 80–85%) it steps back and its peers absorb the load. If every instance is momentarily saturated, a brand-new request simply waits and retries until one is free — a task that has already started is never abandoned. So the only thing that can be refused is the very first acceptance of a new request at peak, and the client just retries; 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 runs a single instance of each part. Production scales out — more instances absorb more concurrent load with no retrying at all; a rough guide to peak throughput is instances × ~16 node executions in flight, so you size the instance count to the load you expect. 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 the store is momentarily full. A run's working data lives in a fast in-memory store with a short lifetime — a finished or abandoned run's data is reclaimed within about a minute, while a live run's is kept fresh for as long as it runs. If enough runs are active at once to fill that store, the platform refuses a brand-new run rather than evict a live one's state — so no running task ever loses its data. That refusal is retryable: as active runs finish and their data reclaims, 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.