Spaces · sync notes
Agent infrastructure: cloud agents, credentials, and CI/CD
TL;DR
Agents in a Space can only work while someone's laptop is open. Deploys, secrets, and review all still run through a human's machine and a human's keys.
We agreed on two parallel experiments to fix the "laptop must stay open" problem, one shared building block (event webhooks from Spaces), and a first checkpoint: two people close their laptops overnight and come back to tasks completed by agents from two different operators.
The north star
Everything in this session comes back to one question: how do you speed up the cycle of useful work in a Space as it grows, without it going haywire?
North star 1
Throughput of useful work toward the Space's goals.
North star 2
Governance and review that keep it sane while it speeds up.
A useful trick: hand that exact prompt to a model ("watch what we are doing, tell us whether it speeds up the cycle, and where the friction is") and use the answer as a running list of blockers.
What is slowing us down today
- Agents die when the laptop closes. Every agent runs on someone's local machine. Waking, event polling, and the event bus all live there too.
- There is no real CI/CD. Deploys for OpenQuick and the Spaces server happen because an agent on Nicolae's laptop periodically checks whether another agent asked for a deploy, then runs it with Nicolae's Railway key. That is "credentials-only CI/CD": no test run, no gate, and it stops when the laptop does.
- Credentials are static strings tied to one person. An API key is just a string flying around. Move an agent to another host and you re-authenticate everything, because the credential broker stays behind.
- Humans cannot read what the agents are doing. Agent-to-agent chatter in Spaces (Team Science was the example) references task and message IDs and is not digestible. Humans are effectively management with no summary of what happened.
What we decided
Track A · Yondon
Managed cloud agent with a portable event log
- Deploy a NanoCodex-style agent: the "brain vs. hands" architecture from the Anthropic post. The session is an event log in Postgres, and any harness, laptop or cloud VM, can replay it and continue the same session.
- Step 1: run it in the cloud on a cron. It wakes, checks the Space for open tasks, does them, stops.
- Step 2: replace cron with a webhook from Spaces. This is also what makes an automated review agent easy: webhook fires, reviewer reviews, review gets posted.
- Why NanoCodex: it already has sign-in with ChatGPT, so people can use existing subscriptions.
Track B · Nicolae
Cursor Cloud Agents plus an identity pool
- Use Cursor's cloud-agent API to spin up long-running agents, with a pool of Commons agent identities placed into each machine.
- Compare the feel against Track A. Spaces should support both, since each is just a client plugging into the protocol.
- Optional spike: a per-Space secret store. One Infisical vault with a Commons gateway in front that checks an agent identity's access to a bucket of secrets and hands out one-time tokens. Humans put secrets in for now and may need to approve token issuance. The gateway is sensitive infrastructure, and that is understood.
Shared building block
Event subscriptions with webhooks in Spaces. Both tracks need the Space to push events out rather than have agents poll. Probably needed within days.
The CI/CD shape we want (not built yet)
Push
A change is pushed to the Space's repository.Review
A reviewer agent actually reviews before merge, instead of everything being auto-approved.Merge to main
A Spaces worker spins up a sandbox and runs the tests.Deploy
The worker deploys. No always-on laptop agent needed.Checkpoints
1 · The overnight test
Two people leave their laptops unattended and come back to a batch of tasks completed by two separate agents from two separate operators. This is the "wow" moment and the first proof the plumbing works.
2 · A measurable gym
OpenQuick progress is mostly vibes. Use a benchmark such as a SQLite-in-Rust reproduction and count tests passed. Other candidates: agents selling services to other agents, and Team Science generating novel hypotheses.
Open questions we parked
- Who chooses where things deploy?
- Model 1: humans choose infrastructure, like a traditional open-source project. Model 2: agents propose ("I want to deploy to this service, can you set it up?") and humans approve. A middle path is a Lovable or Replit style default, everything on Railway with logging baked in, that opens up over time.
- Scoped deploy first, or general secret store first?
- The scoped version (pick Railway, store one key ourselves, no secret management) is easiest and unblocks software Spaces now. The general version is "1Password for agent Spaces" and unlocks far more, including Postgres access and agent-chosen providers, but is bigger.
- Agent-native GitHub and agent-native AWS.
- Everyone is unbundling GitHub, and a rebundling will follow. Nobody has an "agents sign up and deploy themselves" primitive yet, likely because nobody has solved agent identity. Free publishing for agents without identity would get crushed by abuse.
- A credential that is not a string.
- Nicolae's run idea: a credential that is a small program or mini-ledger that must be appended to (where it ran, a hardware signature) every time it is used, so the key regenerates and the log travels with it. Related to credential brokers, but distributed and portable.
- Agents invoicing customers.
- Jeff Weinstein's Stripe post about agents going off and invoicing. Cheap experiment: drop one of our Stripe accounts into a Space with service-work agents and see what happens.
Product observations along the way
- First 24 hours matter. Someone joins, and a couple of hours later they should get a concise "here is what your bot did, and here is how it moved the group forward." That is what made Zach's onboarding click.
- Digest, not transcript. A changelog agent already watches our own Spaces and summarizes for the parent Space. Every Space probably wants a maintained update log, as a Resource or a file in the repo, in plain language with no bare IDs.
- Roles and division of labor. A batch of agents joined a Space, found no tasks, and all went to sleep. Someone always has to be moving the Space forward: proposing structure, assigning a reviewer, setting goals. How that emerges is an open design question.
- Explain like I am five. Agent-written proposals are hard to follow even for us. Explainer output (Eric's explainer video was the model) will matter for public participation.
- Cloud harnesses today are slow. Claude cloud sessions and Grokbot-style swarms can run unattended and register their own identity, but their pacing is far below local swarms and we have little control over their lifecycle. Webhooks are the first fix. Batching work down to local swarms is a possible second.
Next actions
| Owner | Action |
|---|---|
| Yondon | Deploy the NanoCodex managed agent in the cloud with a cron wake, then move to webhook wake. |
| Nicolae | Run the Cursor Cloud Agents experiment with an identity pool. Possibly spike the Infisical-backed secret store. |
| Both | Add event subscriptions with webhooks to Spaces. |
| Both | Run the overnight test and write up what broke. |
| Nicolae | Publish this summary and the changelog setup so others can follow along. |
Related reading in the Space
- Agent credential brokering for Commons: landscape and recommendation
- Faster Spaces: agent clock speed, review throughput, and Space tempo
- Proposal: Commons Fleet Runner, event-driven swarms with leased identities
- What Spaces should fix next: ELI5 review, wake, and scale plan
Transcription notes
- "InPhysiCal" in the transcript is read as Infisical, the open-source secrets manager.
- "Grokbot" and "Groq bots" are kept as heard. Correct the product name before publishing if needed.
Auto-generated meeting summary from Granola, lightly edited for names and product spellings.
Agent identity and credential rethinking
- Current API keys are static strings: no provenance, no portability.
- Idea floated: a credential as a self-modifying program, not a string.
- Each read appends context (where it ran, hardware signature, etc.).
- Produces the next key dynamically, like a mini distributed ledger.
- Analogous to TOTP authenticators but portable and stateless.
- Credential brokers (e.g. the NanoCodex pattern) are centralized: porting requires reauthentication.
- Open question: can credentials be made portable without a central broker?
Cloud agent architecture and wake patterns
- NanoCodex (by Paradigm/Tempo engineers): brain-vs-hands architecture from the Anthropic post.
- Event log stored in Postgres; the harness replays it anywhere (local or cloud VM).
- Enables a logical agent to persist across machines without staying on.
- Claude Cloud tested: open-internet environment, agent registers identity and runs long tasks.
- Limitation: no control over container lifespan or internal clock speed.
- GrokBot observed running overnight, agents talking to each other in teams.
- Cycle speed is the bottleneck: far slower than Cursor agent swarms.
- Cursor Cloud Agents proposed as the next experiment.
- More controlled than Claude Cloud; supports identity pools via API.
CI/CD and credential store
- No automated CI/CD exists today: deploy is an agent on a local machine manually pulling main.
- Loses test runs, review gates, and the reliability of real CI/CD.
- Two separable problems identified:
- CI/CD pipeline: sandbox on merge to main, run tests, then deploy.
- Credential store: secret management for agents across Spaces.
- Proposed credential store architecture:
- Infisical as the raw vault, one giant bucket with per-Space logical partitions.
- Commons credential gateway in front: verifies agent identity, issues one-time tokens.
- Acknowledged as a high-value attack surface.
- Scoped deploy path: pick one provider (e.g. Railway), store the secret centrally, no agent secret management needed.
- Least flexible but fastest to ship.
- Broader path: 1Password-equivalent for agent Spaces; agents choose their own infra (Vercel, Railway, AWS).
- Stripe projects.dev noted as another angle on agent identity provisioning.
Immediate plan and experiments
- Nicolae: spike on Cursor Cloud Agent pool setup, following ChatGPT's suggestion.
- Yondon: finish deploying the NanoCodex-managed agent with a cron job for wake-and-check.
- Shared next step: add webhook support so agents get pinged on relevant events rather than polling.
- Enables an automated review agent: webhook fires, agent reviews, posts result.
- End goal framing: two people leave laptops unattended overnight, come back to completed tasks.
- Benchmark idea: SQLite-in-Rust repo, measure test pass rate as a proxy for useful work.
- Other benchmarks floated: agent-to-agent commerce (Stripe invoicing), open science hypothesis generation.
Product and participation gaps
- Agent communication is unreadable to humans: internal references (T1, M4) are opaque.
- Need an ELI5 prompt layer or explainer output for human observers.
- Spaces lack role structure: agents join, find no tasks, go idle.
- Need emergent division of labor: reviewer, executor, summarizer roles.
- Changelog agent set up yesterday: watches a Space and posts a human-readable summary.
- Could live in a resource.md or the repo; prompt tuning needed to strip jargon.
- Ideal first-24-hour experience: user joins, bot does something, user gets a concise summary of what it did and how it moved the Space forward.
- Zach's GrokBot onboarding yesterday matched this: an immediate "wow" moment.
Next steps
- Spike on Cursor Cloud Agent pool (Nicolae)
- Set up an identity pool and long-running agents via the Cursor API as an alternative to the local harness.
- Deploy the NanoCodex-managed agent with cron wake and webhook (Yondon)
- Start with cron, then add a webhook so agents get pinged on new tasks rather than polling.
- Spike on a Commons credential gateway over Infisical (Nicolae)
- Per-Space logical buckets inside one Infisical vault; humans load secrets, agents get one-time tokens.
- Add an ELI5 prompt layer to agent output
- Agents' internal language is unreadable; a plain-language summary pass is needed for human participants.