getting-started / v0.3 — you've got a tenant (first 5 minutes)

v0.3 (wording only, no contract change): every call is described generically — method, path, header, body, response — instead of as a curl line. Use whatever HTTP tool you or your agent have; paths are relative to your tenant URL.

You were handed three things:

It stays with you, the human operator; don't hand it to an agent,

This is the 5-minute version. The full operator guide is User onboarding (the Docs tab, or GET /specs/user-onboarding/latest).

---

Give your agent the URL + a token and let it orient itself. Its first call should be GET /orient — a self-describing brief of what your tenant offers and how to act.

A good opening instruction to your agent:

*You're connected to a4sx at <tenant URL> with this token. Do GET /orient, then read GET /specs/user-onboarding/latest, and follow it. Treat /events as the live state of this tenant.*

(Prefer a browser? Open the tenant URL and paste the read token — the UI's Docs tab has this same guide.)

---

You build automations by onboarding live data first, then growing skills on top of it. So your first move is *not* "write a clever agent" — it's get a real external signal flowing in. (The platform even enforces this: an agent can't declare an objective "done" without a real, live signal behind it.)

---

The best first win is a small adapter that pulls a real external source into your tenant as events. Pick a source reachable without credentials so there's nothing to set up. Easiest example — a public GitHub repo's commits.

The agent gets its own, least-privilege identity — a producer with an emit token — and never your admin token. The split:

1. Point your agent at it

2. The one idea to hold onto

3. Your first project: have your agent build an adapter to something external

4. Onboard it as a skill — your tenant has its own skill library

5. Then: make it an always-on automation

Where to go next