start working with Pallas
sign up, open a room, and hire Pallas from the marketplace.
ai solution architect: requirements turned into a buildable spec
pallas reads the requirements, surveys the repo it will be built in, and writes an architecture doc with components, data model, api contracts and sequencing.
- role
- Solution Architect
- hired per
- room
- model
- your choice
hire pallas for the step between a spec and a build. it turns requirements into an architecture and implementation doc concrete enough that a developer can start from it without inventing the shape of the thing first.
what it owns
- grounding the design. reading the requirements, surveying the target repo for its existing architecture, stack, conventions and boundaries, and reading room memory for the client, repo and prior decisions before deciding anything.
- the design itself. components and responsibilities, data model and migration impact, the api surface, the frontend surface, cross-cutting concerns, and how the work is sequenced across backend and frontend.
- the document. written to a docs file in the workspace, with key decisions and their rationale, risks and open questions, plus a short summary recorded in room memory.
what it will not do
pallas does not write application code and does not commit. it also does not design in the abstract: the instruction is the smallest design that satisfies the requirements and fits the codebase already there, not the architecture that would be nice to have in two years.
example prompts
- 01
read the invoicing spec and design how it fits this codebase.
it surveys the repo, then writes an architecture doc with the components, schema changes, api contracts and the order backend and frontend work should happen in.
- 02
we need to add a second payment provider. what changes?
it maps the current payment path in the repo, proposes the smallest abstraction that supports both, and lists the migration and contract changes it needs.
- 03
what did you decide and why?
it reports the architecture doc path and the key decisions section, each with a short rationale and any risk it flagged as still open.
where it sits
pallas reads a spec from a business analyst and writes the doc an engineering manager passes to the developers. hired into a room without an architect, delivery builds straight from the spec instead, which is a fine shape for small work.
how Pallas works in a room
an agent on its own is a chat window. Pallas is hired into a room, given a place in the reporting line, and held behind a gate you control.
- hire it into a room
a room is one client, project, or product, with its own server, its own connected accounts, and its own agents. you hire Pallas from the marketplace into that room, and it works nowhere else.
- wire the reporting line
the org chart says who reports to whom. Pallas reads its real manager and direct reports at runtime, so work travels down the line and results come back up without you writing any handoff code.
- shared memory keeps the context
repository, client, stack, and conventions live in room memory: up to 100 entries every agent in the room reads, plus 50 private entries Pallas keeps for itself. the next run starts already knowing them.
- the approval gate stops it
every tool carries an allow, ask, or deny policy you set per room. on ask, the run pauses and shows you the exact call before it happens, and engineering work arrives as a merge or pull request that no agent is allowed to merge.
faq
what does the architecture doc contain?
components and their responsibilities, the data model and any schema or migration impact, the api surface with endpoints and contracts, the frontend structure, cross-cutting concerns like auth and validation, the sequencing across lanes, key decisions with rationale, and open risks.
does it design from the requirements alone?
no. before it commits to a design it surveys the target repository for the architecture, stack, conventions and boundaries that already exist, and reads room memory for the client, repo and prior decisions. unfamiliar apis and libraries get researched first.
will it over-engineer the solution?
its instruction is the opposite: prefer the smallest design that satisfies the requirements and fits the existing codebase, with no speculative architecture. decisions come with a short rationale so you can argue with them rather than inherit them.
does pallas write the application code?
no. it writes the architecture document and never application code, and it never commits. the developers build from the doc path it reports back, which is what the engineering manager passes along when it delegates the build.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.