aevatar-platform-map

Aevatar control plane — the map

You are the router and reference for the Aevatar skill family — you do not execute the work yourself. Your job: orient the agent (object model, auth, caller mode), then hand off to the one companion skill that owns the step the user is on. Read this map first; each spoke is self-contained, so you can also jump straight in once you know the step.

What Aevatar is. A control plane whose client surface is driven over REST at https://aevatar-console-backend-api.aevatar.ai, with separate in-session capabilities exposed as tools. Build/operate resources are owned under a scope (the NyxID subject id); Agent Profile is an independent resource surface:

scope
  ├── teams → members                         authority and ownership
  ├── workflow drafts / definitions           workflowId
  ├── member implementation editor            .../members/{memberId}/workflow
  ├── published callable services             publishedServiceId
  ├── schedules / external triggers           target callable contracts
  └── run / read-model observability           reports committed and materialized facts

Agent Profile
  └── ownerHandle/profileSlug → opaque profileId → draft / published snapshot

These are associations between independently identified resources, not phases of one global lifecycle. "Who is this agent and what may it do?" belongs to Agent Profile; it is not a workflow/member/service operation. Creating a Profile creates no workflow, member, team, service, or schedule.

memberId, workflowId, and publishedServiceId are separate identities. Never pass a workflowId to a member API, a memberId to a workflow-draft API, or either as a publishedServiceId. Resolve every conversion from an explicit backend contract/read model, never from equality, prefixes, or route position. profileId, schedule IDs, Agent Key IDs, UserService IDs, catalog service IDs, and conversation actor IDs are distinct again.

Settle four things before you route (each has a full section below — this is the checklist):

1. Which surface and which resource owner is this? Build/operate or Agent Profile — and if it's a schedule, which of the three scheduling resources owns it (see Scheduling is three resources). Routing to the wrong owner makes everything downstream wrong.
2. Is it even feasible? For anything non-trivial, start with aevatar-feasibility-advisor — it says whether the goal is possible and what must be in place first (which NyxID connector to configure, what's host-gated, what's simply not deployed, what's impossible + the alternative). Don't build something that can't ship.
3. Which caller mode are you in? A plain-REST client holding a NyxID bearer, or the model running in-session with server-side tools? Only aevatar-workflow-authoring needs the server-side tools; everything else is REST either way. See Two caller modes.
4. Carry the honesty rules into every hand-off — you make real HTTP calls (no magic server-side action), most steps are async (read state back, never trust a bare 2xx), and NyxID registration is host-gated. See Honesty rules.

Then match the user's words to a step in the router below, load that skill, and don't reinvent what a spoke already owns.