Agent? Fetch sharkmagic.si/docs/llms.txt or this page as markdown

Fit finder: where Shark fits in your agent stack#

Paste the prompt below into the coding agent that has your repo (Codex, Claude Code, Cursor…). It maps your deployed agents, finds where compute sits idle, and says where Shark fits, where it does not, and what it would take. It changes no code and asks for no secrets. Read its report yourself; send us only what you choose to (rough numbers are enough).

You are auditing this repository's deployed AI agents and workflows to find where per-command, serverless sandboxes
would save money or remove infrastructure, and where they would not. Do not modify any file. Do not print secrets,
API keys, customer names, customer data or prompts: refer to clients as "client A, B…" and to secrets by variable name.

Background on the option being evaluated (Shark Magic):
- Each agent/workflow gets a persistent "Space": files, installed dependencies and caches persist between runs.
- Each command or code execution runs in a fresh Linux microVM (Firecracker) on that Space: normal bash, python, node,
  apt packages, outbound network. The VM exists only while the command runs (~44-65 ms overhead per command), so time
  spent waiting on the LLM, on APIs, on a queue or on a cron schedule costs nothing.
- Postgres and Redis can run per Space as services that sleep when idle and wake on connection (~40 ms).
- Many commands can run in parallel on separate Spaces or forks of one Space, so bursts do not need a queue sized for
  the biggest job.
- Driven by HTTP API, Python/TypeScript SDKs or a CLI; coding agents (Claude Code, Codex) can point their shell at it.
- Dev servers and APIs can run as exposed processes that sleep when idle, with private preview URLs (CLI and API; no
  SDK method yet).
- Not available today: GPUs; a browser session kept open across steps (a headless browser that runs inside one
  command works); Windows/macOS.

Do this:

1. Inventory. List every deployed agent, workflow, worker, cron job, queue consumer or serverless function in the
   repo (look at deployment files: Dockerfile, docker-compose, k8s/helm, Terraform, fly/railway/render configs,
   Prefect/Airflow/Temporal/Celery definitions, GitHub Actions, Procfiles, cron specs, Modal/E2B/Daytona usage).
   For each one record: name, trigger (user, webhook, cron, queue, email…), framework (smolagents, LangGraph,
   custom loop…), where it runs today and on what size (vCPU/RAM/disk), and which services it needs (Postgres,
   PostGIS, Redis, object storage, SharePoint, browser…).

2. Where compute is actually used. For each workflow, trace the steps of one run and classify each step as:
   LLM call | external API/web call | code execution (agent-written code, scripts) | file processing
   (download, unzip, parse documents) | browser automation | database query | waiting (queue, sleep, human).
   Point to the functions/files that do each step. Estimate (rough is fine, say how you estimated) the run's total
   duration and the share of it where a CPU is doing real work vs. waiting.

3. Idle cost. From deployment configs and any billing/infra notes in the repo, estimate what each workflow's
   compute costs per month and what share of that is paying for machines that are waiting. Note machines sized
   for the worst case (e.g. a large VM kept for one heavy job) and concurrency limits or queues that exist only
   because the infrastructure cannot run more at once.

4. Fit. For each workflow, give one verdict with a one-line reason:
   - FIT-EXEC: agent-written code or scripts run in a sandbox per execution (e.g. replace a local/Docker/E2B code
     executor; in smolagents this is the code executor backend).
   - FIT-SPACE: needs persistent files/deps/database between runs but sits idle most of the time.
   - FIT-BURST: heavy, spiky jobs (large downloads, unzip, parsing, builds, tests) that today wait in a queue or
     need an oversized machine.
   - NO-FIT: pure LLM/API orchestration with no code execution (a plain serverless function is cheaper), needs a GPU,
     needs a process to stay up continuously, or needs something listed above as not available.
   - UNSURE: say what information is missing.

5. Integration point. For each FIT, name the single place where the sandbox would plug in (file and function), what
   would be sent to it (command, files) and what comes back, and what secrets it would need (names only). Do not
   write the integration.

6. Report. Output a markdown report: a table (workflow | trigger | runs/day | duration | busy % | today's monthly
   cost | verdict | integration point), then the top 3 opportunities with estimated monthly savings ranges, then
   the risks and unknowns. Keep it under two pages. Mark every number as measured, from config, or estimated.

What we do with what you send: compare it against the measured profile of other agent workloads and tell you, in one page, what share of your bill is idle and what it would cost on Shark. If Shark is not cheaper or not a fit for your case, we say so.