Workforce
A named team, not a prompt. The Banister runs on personasTermA named role with a written charter — the Banister's unit of work, not a chatbot personality. — named roles with written charters, each a real working session with its own identity and lane. Today the platform runs a roster of 40-plus named personas — a working system, not a concept.
The anatomy of a baluster
A persona — a baluster, one spindle in the Banister — isn't a chatbot personality. It's a durable worker with seven distinct parts. Each is separable, which is what lets it be governed, relocated, and stamped fresh for a new client. Click any part of the figure:
Click any part — keyboard works too
Ask any baluster at any time: "who are you?" The answer must be its own name and charter — never the project it happens to be standing in. Identity comes from the launch flag, not from whatever documentation is lying around.
What you get: a named team
The payoff is an actual working org, not a single assistant. The personas compose into a team you can point at real work — someone orchestrating, specialists each in their own lane, an architect gating technical change, a librarian holding the knowledge, and an advisor guarding money and outbound. Today that roster runs 40-plus named members. Because a new member is stamped from one canonical template rather than hand-built, a whole team can be stood up for a new client in days, not quarters.
And it runs on any model — or any agent. A baluster's identity and charter are kept separate from the engine underneath, so it can run on whatever model fits the job, and you're never locked to one vendor.
The seven parts, one by one
- Identity — the head. Its own name and role, stable across sessions. The acid test: ask any baluster "who are you?" and it answers with its own name and charter — never the project it happens to be working in. That one test catches a whole class of identity-confusion bugs.
- Charter — the chest. Its written role, its lane, and the gates it must honor. The charter is the contract; the baluster conforms to it.
- Tools — the hands. The specific things it's allowed to do — read a repo, write a doc, query a database, draft a message. It holds only the tools its charter grants.
- Memory — its own store. A knowledge base curated for it (cleaned, compressed, corrected) so it reasons from grounded, provenance-tracked knowledge, not guesses (Layer 4).
- Boundaries — the spine. What it will not cross. A baluster structurally can't read a peer's private data or act outside its lane — the boundary is in the architecture, not a policy promise.
- Gates — the feet. Where it produces work, one step at a time — and where a human can allow it or halt it. Work is produced by walking the steps; the irreversible ones wait for a human's word.
- Triggers — the plug into the bus. How it wakes and gets work: a message on the bus, a scheduled sweep, an inbound email, or a human's ask.
The team it forms
Personas compose into a working org: a director orchestrating, specialists in their lanes, an architect gating technical change, a librarian holding the knowledge, an advisor guarding money and outbound. They talk to each other over the bus (Layer 5), run work on the board (Layer 3), and escalate to a human only at real gates.
How new members are added
- Stamped, not hand-built. A new persona is minted from a canonical template — one source of truth, copied at stamp time, changes propagated by ledger. This is the mechanism behind "stand up a whole team for a new client in days" rather than writing one from scratch.
- Role stays separate from runtime. The team's registration (who it is, how it's reached) is kept apart from where it runs — so scaling from a laptop to the cloud doesn't rewrite the team.
