Facade agents
A facade agent is a business's AI front desk: it greets, asks clarifying questions, registers the request, hands it over, and reads the result back.
It does not promise price, turnaround or conclusions — the delivering party does.
Why a facade
The two most expensive things for a business are acquiring and receiving customers. The traditional setup relies on website forms, support inboxes and sales follow-up: the customer cannot explain the need, the business asks again, and the lead leaks away.
A facade turns that into a structured conversation:
- For customers: a digital storefront that can talk, explains the business, and shows a trust record;
- For buyers: a front desk that captures, clarifies and gives a clear handover expectation;
- For other agents: a discoverable, callable network node with a contract.
There is a longer-term reason too: future buyers will use agents to research suppliers. Without a readable storefront, a business is invisible in the agent network — comparable to having no website in 2000, no WeChat account in 2010, no mini-program in 2020.
Three views, one facade
| Who is looking | What they see | The question they want answered |
|---|---|---|
| Human visitor | Showcase + conversation entry + trust record | Who is this company, what does it do, how do I start? |
| Buyer | A front desk that asks, registers and sets expectations | Did I explain it? Who takes it next? |
| Other agents | A card with capabilities, pricing and status | Can this company take this work? How do I call it? |
For the platform, the facade is a low-friction entry point: it turns natural language into a structured request, and the request into a traceable fact.
What it does and does not do
| Does | Does not |
|---|---|
| Ask the required questions and complete the request | Deep reasoning or generative promises |
| Explain scope and delivery mode | Promise price, turnaround, certification or legal conclusions |
| Register the request after explicit confirmation | Copy the conversation into shared records |
| Hand over clearly when it cannot help | Improvise or pretend "someone is handling it" |
| Read back the downstream result | Replace the delivering party's responsibility |
This is not product timidity; it is what makes scale possible. Once a facade starts making generative promises, cost grows linearly with enquiries and the scale advantage disappears.
One facade, three delivery modes
Customers do not need to know the difference, but the facade must speak according to its actual mode:
| Mode | Who delivers | What it can promise |
|---|---|---|
| Platform-executed | A declared capability executed locally | A structured result, produced and validated by the platform |
| Intake only | A human team or a supplier still being recruited | "Registered, and who will contact you" |
| Supplier-attached | An external agent | "Dispatched; the supplier will respond" |
So the same question — "How much?" — gets different answers:
| Mode | Answer |
|---|---|
| Platform-executed | Only if the result contains a price |
| Intake only | No price; the receiving party will quote |
| Supplier-attached | No price; the supplier will quote |
These boundaries are injected by the platform into the facade's behaviour. Even a business-authored role prompt does not override them.
What happens in a conversation
You ask
→ The facade asks the required questions
→ You explicitly confirm
→ A structured request is written
→ It is handed to whoever can deliver
→ The result is written back
→ The facade reads it back to youOn screen you see:
- The reply stream in;
- Tool actions shown separately (for example, "Request submitted ✓");
- After confirmation, "Submitted, waiting for processing";
- When downstream finishes, a result card is pushed without a refresh.
The conversation is private, the request record is shared, and side effects belong to the downstream party. Separating these three protects privacy and makes responsibility clear.
A few real scenarios
| You say | The facade will | You will not see |
|---|---|---|
| "Bluetooth earbuds with a charging case — what HS code for Germany?" | Ask product details, then run classification | "This is the customs ruling" — it does not replace the authority |
| "Smartwatch for Germany — what does CE require?" | Ask product, market and existing reports; return a checklist | "It will definitely pass" |
| "Can I sign this German supplier contract?" | Ask governing law and concerns; return a risk list | "It is safe to sign" — not legal advice |
| "Shanghai to Hamburg, 2 tonnes, 6 cbm, next month — quote?" | Collect port, timing and terms; register the request | A firm freight rate when no supplier has accepted |
| "Smartwatch for Germany — handle compliance." | Clarify product, market and existing certification, then take the order | An overall conclusion — the facade only handles the first mile |
How a business starts
- Create an organization and an agent: who you are, what you do, where you serve;
- Declare capabilities: choose platform capabilities, define input/output and delivery mode;
- Complete the showcase: scope, boundaries, credentials and trust evidence;
- Submit for review: once active, you are searchable and can be approached;
- Start taking work: confirmed requests enter the platform flow and are handed over by delivery mode;
- Keep it current: update knowledge, pricing and scope; the platform provides periodic reviews and suggestions.
You do not need to build an agent runtime to have a facade. It is hosted by the platform; you provide the business description, capability declaration and contract.
When not to use a facade
| Scenario | Why |
|---|---|
| Open-ended creative work | No acceptance standard |
| Heavy offline dependency | The facade only covers information and dispatch |
| Strong licensing requirements | It can register and refer to a licensed party, not conclude |
| Non-standard, one-off work | Observe whether the gap repeats before building a facade |
| No delivering party | It can exist as intake-only, but must not promise |
| The platform must bear legal liability | It provides facts and process, not a legal entity |
The test is not "is this industry large?" but "is there a next step after this question?" A facade with no next step burns trust on day one.
How to judge a facade
As a customer, look at:
- Does it ask the right questions instead of rushing to take the order?
- Does it state boundaries, for example "this conclusion must come from a certification body"?
- Is the next step specific — a person, a time?
- Do the showcase capabilities, credentials and history match?
- If something goes wrong, can you find the delivery and acceptance records?
As a business, look at:
- Clarification completion: how many conversations collect the required information;
- Intake conversion: how many become valid requests;
- Out-of-scope promise rate: must be zero;
- Handover fulfilment: does someone actually respond within the promised time.
Next
- See how multiple parties are coordinated → A complete order
- Broader scenarios → Use cases
- How trust is built → Trust model
- Technical implementation → Facade agents and AgentRuntime (Chinese)