Short version: one specialist teaches the AI to phrase good answers. The other decides which questions it’s even allowed to answer on its own. Different jobs — constantly confused for each other.
Every other conversation with a founder starts the same way: “We already have a prompt engineer — why do we need an architect too?” It’s a fair question. From the outside, both roles look like tuning AI for a task. In practice, they’re different professions solving unrelated problems, and one doesn’t replace the other.
What a prompt engineer does
A prompt engineer takes a ready-made language model and tunes it for a specific task: writing and refining instructions, testing different phrasings, getting a stable and predictable response. This is careful, important work — the quality of the prompt directly determines how precisely and smoothly the product answers the user.
What a legal architect does
A prompt engineer works with form: how the model phrases a response, what role and tone it takes, whether it sounds convincing. A legal architect works at a different level — with what the system is allowed to do at all, and with the boundary of responsibility: which decisions a product may hand to an algorithm, and which it must route to a human.
The architect’s job is to design the logic so the algorithm’s actual behavior never gives a regulator or a client grounds for a complaint. The prompt engineer is responsible for something else: making sure the model’s answer doesn’t drift.
This is the logic of what’s permitted for the model — specifically the legal and risk layer of product logic, not the whole product. That includes:
- decision trees;
- a Red Flags matrix;
- escalation criteria — when a decision has to go to a human.
That’s the framework a prompt engineer then works inside. Everything else about the product — what’s shown to the user, how the interface looks — is still the product manager’s call.
An everyday example: think of a restaurant. A waiter can describe a dish beautifully and talk a guest into ordering it — but they don’t decide what’s allowed on the menu at all: whether food-safety rules are met, whether allergens are disclosed, whether an ingredient is even fit to serve.
Someone else sets those boundaries, long before the waiter reaches the table.
The prompt engineer is the waiter. The legal architect is the one who decides what can go on the plate in the first place.
Where the line falls: an example
The same principle shows up in a more technical example — automated client onboarding at a neobank. An application gets processed by an algorithm, not a person, and this is exactly where the roles need to be kept separate:
- The architect sets a hard rule: if the client is a politically exposed person, automation doesn’t approve the application on its own — it routes the case to a compliance officer for enhanced review. If the client turns up on a sanctions or anti-money-laundering list, the operation is blocked outright.
- The developer wires that rule to an API check against official registries. Screening for PEP status and AML lists in fintech always runs through a query with a fixed, predictable outcome — never through a language model.
- The prompt engineer comes in at the next step, where the job is text, not a decision: phrasing a polite, legally sound request for additional documents without revealing exactly what triggered the flag, or summarizing the client’s file for the compliance officer.
Without the rule the architect sets, the prompt engineer simply has nothing to work with: the decision about who gets escalated is made earlier, with no language model involved.
Why you need both roles
This isn’t competition for budget or an either/or choice — it’s sequential work.
A legal architect designs the logic once, up front, and updates it as legislation changes (that’s what the Legal Maintenance format on the service page is for). A prompt engineer tunes the model to that logic and keeps adjusting it as the product grows.
Hire only a prompt engineer, and you’re trusting someone who isn’t required to understand the boundaries of liability to decide where they lie. Hire only an architect, and you get the right logic with no one to hand it to the model reliably.
An everyday example: in that same restaurant, two waiters can work under the exact same rules — what’s allowed on the menu, what isn’t. One defuses a guest’s complaint with a couple of well-chosen sentences and gets a good tip; the other turns a minor gripe into a scene and a formal complaint over one clumsy sentence. The right boundaries don’t save a bad delivery — these are two different, equally necessary skills.
Frequently asked questions
Can a prompt engineer just define these rules themselves? Sometimes they try — and it’s a common source of trouble. A prompt engineer usually isn’t a lawyer and isn’t required to know which legal requirements and risks sit behind a given scenario.
A beautifully written prompt on top of missing legal logic doesn’t help: the model doesn’t understand when it needs to stop and hand a case to a person, but it answers just as confidently as if it had the right answer.
We already have an in-house lawyer — shouldn’t they define these rules? An in-house lawyer knows the law well, but usually thinks in terms of statutes and litigation, not data structures — decision trees and a system’s rare edge cases.
Assembling a calibration dataset — a set of test cases used to check the code behaves correctly — is a distinct skill at the intersection of law and systems design that a legal education on its own doesn’t provide. A legal architect translates a lawyer’s expertise into a format that can go straight to a developer and a prompt engineer.
Where do we start if we already have a developer and a prompt engineer, but no legal logic? With the Core Architecture & Triage Logic format — designing the logic from scratch.
The output is a complete technical spec for developers:
- decision trees;
- a Red Flags matrix;
- escalation criteria — when a decision has to go to a human.
All of it delivered as structured data files (JSON schemas) and technical specifications that the team drops straight into prompts and code.
Already using a prompt engineer but feel like your product’s logic is missing guardrails? See how legal architecture works — the formats, and exactly what I hand off to the team. And if you already have a team building the platform — how an architect differs from a developer is covered separately.