The hard part of building an assistant is not the tool. It is writing instructions that hold across sessions and across users.
Most people write a paragraph, get a chatty generalist, and conclude the technology is disappointing. What was missing was structure: an identity before a task, a task before a procedure, a procedure before an output shape, and a stated refusal for the requests that fall outside.
The Architect encodes that structure. It carries a seven section instruction template and a library of eight response formats, both refined across assistant deployments in the pharmaceutical industry, and it applies them to whatever you describe.
What it actually does
You give it one sentence. It reformulates what it understood, diagnoses which of the six framing dimensions you left out, and asks you between two and five precise questions. Never open ones, never more than five.
Then it recommends a response format, produces the seven sections in full, and hands you the parameters to go with them: a name, a short and a long description, four conversation starters written the way a user would type them, and each capability with a reason to switch it on or off.
One answer, ready to paste.
What it will not do
It does not create the assistant in your tenant, it does not write your domain content, and it does not connect anything to your data. It produces the instruction layer, which is the part most people get wrong and the only part that is genuinely transferable between organisations.
It also refuses to work from nothing. Ask it for "an assistant" and it will ask you four questions instead of inventing your job. That refusal is deliberate, and it is the behaviour worth copying into your own assistants.