Day 4: From Solo to Team
63 commits. 12,000 lines of code. One question: what happens when it's not just you anymore?
← Day 3: Encryption, Onboarding, and a Trojan Horse
The multi-user problem
Pinchy started as a single-user tool. One admin, one agent, one chat history. Fine for a demo. Useless for a company.
Enterprise means teams. Multiple people, different roles, different agents, different conversations — all on the same instance. Today was about making that work. It touched everything: auth, data isolation, agent lifecycle, the whole stack.
The invite system
There's no "Sign Up" button in Pinchy. That's intentional.
The admin generates invite tokens. New users claim them. Each token is hashed with bcrypt before storage, single-use, and revocable. If you need to onboard someone, you create a token and send it to them. If you change your mind, you revoke it before they use it.
Why not open registration? Because this is enterprise software. You don't want random people creating accounts on your internal AI platform. Controlled onboarding isn't a limitation — it's the feature.
Personal agents
Every user gets their own agent — Smithers — on first login. Your agent, your workspace, your SOUL.md. Nobody else sees your conversations.
This is the core isolation model. Each user's Smithers runs in its own workspace directory. Chat history is scoped per user. When you talk to your agent, it's yours. Not shared, not visible to the admin, not leaking into someone else's context window.
Smithers gets a soul
Speaking of SOUL.md — I wrote one. A real one. Smithers now knows what Pinchy is, what it can do, how to help you navigate the platform, and has an actual personality (helpful, direct, slightly dry humor — think competent butler, not chirpy chatbot).
The SOUL.md gets auto-generated when creating new agents. It's the personality bootstrap — the file that turns a generic LLM session into something that feels like it belongs in the product.
Agent management
Beyond the personal Smithers, you can create additional agents from templates: Knowledge Base (for querying documents) and Custom (blank slate). Admins can delete agents — but not personal ones. You can't accidentally nuke someone's Smithers.
Each agent gets its own workspace directory. This matters for plugins and file access — agents are sandboxed to their own space.
The Pinchy Files plugin
First custom plugin. pinchy-files gives agents scoped read access to mounted data directories. Two tools: pinchy_ls (list directory contents) and pinchy_read (read file contents).
The important part is what it doesn't do: path validation prevents escaping the sandbox. You can't ../../etc/passwd your way out. The agent sees exactly the directories you've mounted for it, nothing more. This is the pattern for all future plugins — scoped access, explicit boundaries.
Chat attachments
Images, text files, clipboard paste. Drop a file into the chat and the agent can see it. Small feature in terms of code, big improvement in terms of what you can actually do with the agent. Screenshots, log files, config snippets — all the things you'd naturally want to share with something that's helping you.
Eating my own dog food
openclaw-node — the npm package I published yesterday — is now a dependency in Pinchy itself. The WebSocket bridge that connects the chat UI to the OpenClaw Gateway uses my own client library.
This is the best kind of quality assurance. When your own tools aren't good enough for your own product, they're not good enough. Every bug in openclaw-node is now a bug in Pinchy. Every rough edge I feel, users would feel. The feedback loop is immediate.
Testing, for real
Not the exciting part. The necessary part.
I set up Playwright for end-to-end testing. Tests cover the setup wizard, login flow, and provider configuration — the critical paths that, if broken, mean nobody can use the product at all.
On top of that: ~30 new unit test files. Auth logic, invite tokens, settings encryption, agent creation. Not glamorous. But this is what separates a prototype from a product. When you're adding multi-user support and touching every layer of the stack, you need to know you haven't broken the single-user stuff.
The numbers
63 commits. 146 files changed. +12,250 lines added. -333 lines removed. Day 4 was the biggest day yet — by a wide margin.
For context: Day 2 was ~2,000 lines. Day 3 was ~7,600 lines. I'm accelerating because the foundation is solid enough to build fast on top of.
What's next
Tomorrow is about polish and the first real user feedback. The LinkedIn post announcing Pinchy got 45 reactions and 22 comments in one day — people want this. Time to make sure it works when they try it.
Day 5: The Enterprise Gauntlet →
This is part of the Building Pinchy in Public series. We're building an open-source web UI for OpenClaw and sharing every decision — technical, strategic, and everything in between.
Follow along: GitHub · ← Day 3: Encryption, Onboarding, and a Trojan Horse