Agent Platform · Spark
No matter who asks, work starts as a work order from the CEO agent, and the server controls delegation and tool execution
An internal platform where agents hand issues to each other to get work done. I forked Paperclip (an open-source agent issue tracker) and attached company features as HTTP services outside the core, under a services folder, instead of putting them in the core. The only exceptions are Work OS (an app for work status, approvals, and run history) and Spark. Staff use Spark to query 4 business DBs read-only, and hand work to the CEO agent. Long delegation chains change the request, and a single tool call can lead to spending money or external exposure. So the controls live in server code, not in prompts.
- The work order's original text is locked with a hash. Each delegation step changes the wording of the request. The original is NFC-normalized, line endings are normalized, and it is locked together with its sha256. The server overwrites any hash the client sends. I followed an external benchmark that found fewer supervisor errors when the original is passed along instead of an intermediate summary.
- The server breaks delegation loops. Plugins can only observe after an issue is created, so I changed the server core. Depth 2, 5 per work order, no A→B→A. Depth is counted by walking up the actual parent issues, not read from a column whose value can be changed. A 6th delegation and forged depth are rejected in tests.
- Jev shortlists; Gemini picks. Jev scores every one of the 100-odd skills and shortlists the top 5, then Gemini picks 1 from that shortlist. On failure, timeout, or an open circuit breaker (300 seconds after 2 failures), Jev is skipped and Gemini picks directly from the full list. Rollout targets are split by the first 8 characters of a sha256.
- An approval is used exactly once. The approval row is locked with FOR UPDATE, and a partial unique index blocks it a second time. The approval is consumed even if execution fails. The idempotency key uses ON CONFLICT DO NOTHING followed by a re-read, so there is no race. A test confirmed 1 execution for 10 concurrent requests.
- Write approvals sign the preview. Input hash, preview hash, requester, run ID, and expiry are bundled as canonical JSON and signed with HMAC-SHA256. Write access to the DB is not enough to pass without the key. The key contains no timestamp, so model retries do not multiply approvals.
- Spark DB lookups open a new connection per query. A read-only role alone was not enough. One set_config call lifts the timeout and read-only mode, and a reused connection hands that state to the next person. After filtering 23 dangerous functions, semicolons, and writing CTEs, it opens 1 connection and closes it when done.
- Expensive queries are rejected before they run. If the EXPLAIN cost exceeds 1,000,000, the query does not run. The 10-second limit is set in two places: the DB setting and a socket close in the app. Results are cut at 500 rows or 100KB. The role has BYPASSRLS so RLS cannot silently empty results, and the audit log keeps only the SQL hash.
- Exceeding the paid cap returns 403, not 429. OpenAI-family SDKs retry 429 and 5xx on their own. So once spend passes 30,000 KRW a day, it returns 403 with x-should-retry: false. The ledger is a Redis key per KST date. Service keys can call only the inference path, and overlapping keys are discarded.
- 100+ shared skills