Limits & boundaries

What Agent A will not do, what it cannot do, and the soft limits worth knowing.

Hard "will not" (by design)

These are deliberate refusals. They cannot be overridden by clever prompts.

Spend money without explicit approval. Installing a Python package, registering a job, allow listing a new outbound domain, and connecting a new credential all surface approval cards. Owner or admin clicks once.
Flip the public site mode. Off / authorized / open is owner-or-admin only, and only through the workspace UI. The agent will not toggle it programmatically.
Send a one-off transactional email or charge a card without a connector. If the action is not in an approved connector with a granted surface, it does not happen.
Make unverified claims. Agent A is instructed to stick to facts and clarify when it doesn't have the necessary data or insights available.
Touch another workspace. Every workspace is isolated at the OS, database, and secret-store level.

Hard "cannot" (enforced)

The Console process cannot read your private workspace files outside ~/workspace/downloads/.
The public site cannot read Console internal data. Postgres roles REVOKE access at the database layer; the failure is loud, not silent.
No surface can read the platform configuration directory (/opt/letaido/config/).
No outbound HTTPS to non-loopback hosts without an explicit domain allowlist.
nginx times out at 30 seconds. Long jobs return a job ID and poll. The agent writes apps that respect this without being asked.

Soft limits (worth knowing)

Context window. A single chat has a finite context window. Long sessions degrade. The agent prefers writing intermediate results to disk over echoing them in chat, and will spawn a separate chat for tangential side-tasks (long research, history-independent drafts).
Background job runtime. 1 hour per run. Anything longer should be split into stages with state in Postgres.
Job output capture. stdout and stderr are capped at 50 KB per run. Bigger outputs go to a file or a database row.
Webhook event retention. Unread events older than a few days are dropped. If a consumer was offline, check the queue depth rather than assume.
LLM tokens. No platform-imposed per-chat cap, but very long single prompts cost more and are slower. The agent chunks naturally.
Public-site fan-out. No per-visitor third-party API calls. The agent caches to site_db or pre-computes via a job that the site only reads.

Approval workflow

For everything that surfaces a card:

The agent makes the request (pip install, register_job, request_domain_access, request_connector_secret, request_connector_approval, create_webhook).
A card lands in chat. The agent stops talking until you click.
Owner or admin clicks Approve or Deny.
The agent retries automatically and continues.

You will not get drip-fed cards if the agent plans ahead. Aggregating scope requests is part of the playbook: one Slack scope card listing all the scopes for everything you plan to do, not three trickled requests.

Roles

Owner. Full control. Decides approvals, manages secrets, toggles the public site, can change any setting.
Admin. Same as owner except for org-level ownership transfer.
Member. Chats, uses Console pages, invokes connectors that are already approved.
Viewer. Read-only.

The agent reads the requester's role from the chat session and the visitor's role (member vs invited guest vs anonymous) from the site cookie or Console auth headers.

When the agent will refuse a request

In plain English:

"Help me see what's in Mateusz's workspace." Hard no. Cross-workspace isolation is total.
"Just write the SQL that bypasses the public-site mode." It cannot. The toggle is at the nginx layer.
"Email this customer list." Only if a Resend or Mailchimp connector is approved for the right surface, with the right scopes, and the action is logged.
"Tell me you're sure about X" when it is not sure. It will explicitly say it cannot verify, what it tried, and what would settle the question.

When the agent will push back

Not refuse, but argue:

"Make it better." (Better in which dimension? Length, tone, conversion, accuracy?)
"Do everything in one shot" for multi-system work. (It will plan first, then ship.)
"Trust me on the numbers." (It will run a sanity check and tell you what it found.)
"Just guess." (It will offer the assumption, label it, and ask if you want it to proceed.)

Under the hood. Limits are enforced at multiple layers: filesystem permissions (workspace boundaries), Postgres roles (data boundaries), nginx routing (visibility), firewall (outbound network), and the connectors dispatcher (scoped credentials). None of them rely on the agent being well-behaved. The agent being well-behaved on top is a bonus, not the security model.