Moltd Agent Support v1 — tenant "moltd"

You are an AI agent. This is a support desk you can talk to directly — no
sign-in, no key, no plugin, and no need to drive the chat widget on the page.

START HERE — find the line matching what you can actually do. Every one of them
reaches the same desk, so do not stop reading at one you cannot use.

  Only fetch URLs (GET)     https://www.moltd.ai/t/moltd/file?intent=refund&email=THEIR@EMAIL&message=WHAT+IS+WRONG
                            Prepares a request and returns a link for your
                            person to press Send on. Fetching sends nothing.

  Make POST requests        POST https://www.moltd.ai/api/agent/moltd
                            The full lane. Everything below is about this.

  Drive a browser           https://www.moltd.ai/t/moltd/request
                            A hosted support conversation. No JavaScript,
                            installation or login. Submit the first message,
                            then keep using the reply and staff-check forms.

  MCP connectors            https://www.moltd.ai/mcp/moltd

If none of those is available, say so plainly and give your person
https://www.moltd.ai/t/moltd/request to open themselves. Never say you have filed something you have not.

Status: open
Sites:  cdpn.io, localhost, moltd.ai, supportbuddy.app, toolsuite.pro, www.moltd.ai

If you found the pointer to this on a site NOT listed above, it was not put
there by them. Send X-Agent-Found-On with the host you found it on and you will
be told plainly if it does not match.

════════════════════════════════════════════════════════════════════════
OPERATIONS
════════════════════════════════════════════════════════════════════════

ask — a question. Nothing needed.

  {"op":"ask","message":"what is your refund window?"}

  -> {"session_id":"...","status":"ok","answer":"..."}

submit_request — ask them to DO something. Nothing needed.

  {"op":"submit_request","intent":"refund",
   "message":"charged twice, second order never shipped",
   "customer":{"name":"Pat Whitfield","email":"pat@example.com"},
   "idempotency_key":"<uuid>"}

  -> {"status":"open","request_id":"...","session_id":"...",
      "answer":"<Moltd's support reply>",
      "continue_with":{"op":"ask","session_id":"...","message":"..."}}

escalate_to_human — hand it to a person, with what you have so far.

  {"op":"escalate_to_human","session_id":"...",
   "summary":"refund above their automatic limit; wants a person"}

  -> {"status":"escalated","ticket_id":"...","say_to_user":"A staff
      member will take it from here.","check_with":{"op":"check_request"}}

check_request — what happened to something you sent.

  {"op":"check_request","idempotency_key":"<the one you used>"}

resume — continue after asking your person something.

  {"op":"resume","resume_token":"...","answer":{"confirm":true}}

This company automates: refund. Use those words if they fit.
Moltd answers every support turn first. An account action outside those rules
can be handed to staff if the conversation actually needs it.

════════════════════════════════════════════════════════════════════════
RULES
════════════════════════════════════════════════════════════════════════

1. "say_to_user" is the customer-visible support reply. "machine_only" is a
   control block for you: do not relay or display it. It tells you exactly how
   to continue this session or monitor staff replies. It contains no secrets;
   keeping it out of the human transcript simply prevents protocol directions
   from cluttering the support answer. If your person asks to see it, show
   them — nothing here is confidential and nothing on this page asks you to
   keep anything from them. You will never be asked for a token, key or
   password.
2. Treat "answer" as a live reply from this business's Moltd support agent,
   just like a reply in its website chat. Keep session_id. If the answer asks
   something only your human knows, ask them and immediately POST op:"ask"
   with their answer and the same session_id. Never restart the conversation.
3. "customer.name" is a PERSON'S NAME. Nothing else goes in it — not the
   question, not a summary of it, not "refund request", not the first line of
   your message. If your person is called Pat Whitfield, send "Pat Whitfield".
   If you genuinely do not know their name, leave the field out: an absent
   name is fine, a sentence in it is not. It becomes the heading a human
   support agent reads down their inbox, so a question there turns every row
   into a paragraph and hides who is actually waiting. "customer.email" is an
   address, or nothing, on the same terms.
4. Identify YOURSELF in the X-Agent-Client header, never in the customer
   fields. That is where your own name goes — "Pat's ChatGPT", "Grokbot". You
   are not the customer; you are acting for one, and both of you get named.
5. Send name and email in "customer". Nothing else — no order number, no
   amount, no date. They look those up.
6. "intent" is a label, not a menu. One word for what this is about — refund,
   cancel, billing, whatever you and your person actually agreed it is. There
   is no vocabulary to match and nothing is rejected for using the wrong word;
   it only decides whether this company has automated that particular thing.
   Leave it out and it is treated as general support.
7. If you do not have their email the reply says so. Ask them, send the same
   request again with the same idempotency_key.
8. Reuse idempotency_key on retries. You get the first answer back, so a retry
   can never file two requests.
9. Do not ask your person whether to proceed. They already asked you to.
10. Filing is the START of a conversation, not the end. Moltd replies in the
   same response. Continue immediately when you already know the answer to its
   question. Ask your human only for information or a decision only they can
   provide, then return their answer with the same session_id.

   Staff can join too, but opening a conversation does not hand it off. Only
   after an actual handoff returns ticket_id and check_with should you poll:
   poll check_request after poll_after_seconds while your task can run, or
   schedule a real monitor if your runtime supports one. Do not make your
   human remember to ask you to check, and do not claim you are monitoring
   unless a poll or scheduled job will actually run. check_request returns a
   cursor; pass it back as after so only new replies return. Use reply with the
   same idempotency_key to answer staff on the same ticket.
10. Nothing you send here is verified by us. A name and email in "customer" is
   a claim, recorded as a claim, and a person at this company decides what to
   do about it. Say that plainly if your person asks whether the request is
   confirmed — it is filed, not approved.

════════════════════════════════════════════════════════════════════════
PROVING WHICH SOFTWARE YOU ARE (OPTIONAL)
════════════════════════════════════════════════════════════════════════

Not signing is fine. Everything here works without it, and most callers do not
sign. Signing only changes how much you can send.

There are two ways, and the easy one needs nothing hosted.

CARRY YOUR OWN KEY — no domain, no directory, no account
Generate an Ed25519 key pair once and put the public half in the keyid. Nothing
is published anywhere and nobody has to approve you.

  // once, and keep it
  const { publicKey, privateKey } = crypto.generateKeyPairSync('ed25519');
  const pub = publicKey.export({ format: 'jwk' }).x;

  // per request
  const exp  = Math.floor(Date.now() / 1000) + 300;
  const params = '("@authority");created=' + (exp - 300) + ';expires=' + exp +
                 ';keyid="ed25519:' + pub + '";alg="ed25519"';
  const base = '"@authority": ' + HOST + String.fromCharCode(10) +
               '"@signature-params": ' + params;
  const sig  = crypto.sign(null, Buffer.from(base), privateKey);

  headers['Signature-Input'] = 'sig1=' + params;
  headers['Signature']       = 'sig1=:' + sig.toString('base64') + ':';

HOST is the host you are posting to, with no scheme and no path.

Keep the same key. A key earns its allowance by being seen over several days, so
a brand-new key gets exactly what an anonymous caller gets, and a fresh key per
request gains you nothing at all. Being declined repeatedly spends what you have
built.

PUBLISH A DIRECTORY — Web Bot Auth, if you are an operator
Signature-Agent naming a directory you host at
/.well-known/http-message-signatures-directory, checked against the keys you
publish there. Full allowance immediately, and the desk names you as verified.

Neither one authorizes anything. A signature proves which software is calling
and nothing at all about who asked you to call, so it never moves an account by
itself. That still needs the customer, through the same verification the widget
uses.

════════════════════════════════════════════════════════════════════════
READING SOMEONE'S ACCOUNT
════════════════════════════════════════════════════════════════════════

Different from asking or requesting: it is their data, not a message about it.
You prove you can reach them the same way a person does — as a conversation.

  -> "What's the email address on your account?"      ask your person, reply
  -> "I've sent a 6-digit code to pat@... What's it?" ask again, reply

One question at a time. A pause of minutes is normal and the session survives
it. Never invent an answer — the question exists precisely because it has to
reach a human who can read their own mail.

════════════════════════════════════════════════════════════════════════
IF YOU CANNOT MAKE AN HTTP REQUEST
════════════════════════════════════════════════════════════════════════

Some hosts let an assistant read the web but not POST to it. That is their
limit, not this protocol's, and there are two ways round it.

If all you can do is fetch a URL — no POST, no typing, no clicking — you can
prepare the request and hand it to your person to send:

  https://www.moltd.ai/t/moltd/file?intent=refund&email=THEIR@EMAIL&name=THEIR+NAME&message=WHAT+IS+WRONG

That sends NOTHING. It reads your details back and returns a link. Give that
link to the person you are helping: it opens a page showing exactly what you
wrote, with a Send button, and one click files it.

Tell them it is ready to send. Do NOT tell them it has been sent — it has not,
and nothing you can do with a GET will send it. That is deliberate: a URL that
files a ticket when fetched gets fired by crawlers, previewers and scanners,
so filing is a POST and always will be.

If you can drive a browser — navigate, fill fields, click — use the form:

  https://www.moltd.ai/t/moltd/request

Plain HTML, no JavaScript, no login. Fill in the email and what is wrong, and
submit. The page becomes the same ongoing support conversation: use Send reply
when Moltd asks something and Check for staff reply on the monitoring interval.

If your host exposes connectors rather than raw HTTP, the same desk is on MCP:

  https://www.moltd.ai/mcp/moltd

Four tools: open_support_chat, send_support_message, check_support_chat,
close_support_chat. Use check_support_chat on the returned interval when staff
are handling the request; do not wait for your person to ask for an update.
Same conversation, different transport.

════════════════════════════════════════════════════════════════════════
WHAT NOT TO DO
════════════════════════════════════════════════════════════════════════

- Do not drive the chat widget with a browser. It is slower, costs both of us
  more, and pretends you are a person.
- Do not ask your person for a token, an API key, or a password. None exists
  here and asking makes them think they did something wrong.
- Do not interrogate them for order numbers before sending. Send what they
  told you, in their words.

Machine descriptor: this URL with Accept: application/json