Skip to main content

Operational limits and reliability

CortexHub bounds agent work so a runaway loop or burst cannot create unbounded provider traffic. Limits can change as the platform evolves; treat an HTTP error, Retry-After, and the returned error code as the source of truth for a live request.

Published limits​

AreaCurrent limit or defaultWhat happens at the boundary
Tool calls per cortexhub_invoke_tools request10 callsThe request is rejected; split the batch.
Tool schemas per schema lookup50 namesThe request is rejected; fetch a smaller batch.
Agent reasoning steps per hosted turn40 by default, 200 platform ceilingThe turn stops with loop_guard_halted. An organisation can tighten the value, never raise it above the ceiling.
Rate governor120 calls per agent/session/60-second window by default; 10 destructive calls per windowFurther calls are denied until the window clears. The always-on platform floor is 60 calls per 10 seconds.
Knowledge and member file upload10 MiB per fileThe upload is rejected with a validation error.
Custom OpenAPI specification5 MiBThe toolkit import is rejected before indexing.
Prompt body24,000 charactersThe prompt write is rejected with a validation error.
MCP stream session24-hour sliding default, with a one-hour minimum refreshReconnect and initialize a new session after expiry.

The platform also applies OAuth endpoint throttles and provider-specific limits. Provider responses are surfaced with a normalized error kind and, when available, a retry delay.

Approval and task reliability​

An approval-gated call is parked as an MCP Task. The agent should poll cortexhub_get_task until terminal is true. The action resumes server-side exactly once after approval; retrying the original invoke creates a new governance decision.

Operator and end-user approvals use the same task record. If a delivery channel is temporarily unavailable, the built-in approval inbox remains available when configured as the fallback.

Retry guidance​

  • Retry network timeouts and tool_unavailable with exponential backoff and a bounded number of attempts.
  • Respect Retry-After when it is returned for a rate limit or provider response.
  • Do not retry policy_denied, invalid credentials, missing entitlement, or a terminal MCP Task without changing the underlying configuration.
  • Use an idempotency key where the downstream operation supports one. A repeated request still passes through policy and may require a new approval.
  • Keep Mcp-Session-Id stable for one conversation and objective stable for one task so operators can reconstruct the trace.

Health and monitoring​

Use the MCP ping method for transport liveness. For production operations, monitor:

  • HTTP 5xx and gateway latency
  • rate-limit and policy-denial rates
  • parked tasks older than your operational threshold
  • provider authentication and availability errors
  • webhook or OTLP delivery failures
  • gateway health and delivery latency in your CortexHub support or operations process

Every governed call produces an audit event and enforcement receipt. Export spans to your OpenTelemetry collector or SIEM when you need independent alerting and retention.

See also​