Entry-agnostic agent (inward/outward symmetry)
Parent: agent-core
The design
The agent is entry-agnostic: entries are just consumers that fill a neutral session context and invoke it.
Capabilities only know "used by an agent" — they read the neutral _meta.standmeet/session sidechannel (see trusted-identity-via-meta, generalized). Connectors only know "resolved by name" (the consumer-agnostic decision).
Consequence
New entries (IM gateway, job-loop outbound) are new consumers; capabilities and connectors remain unchanged. The as-MCP facade is really "another consumer" — unify, don't build twice.
Current state
As of 2026-09-07 (36789537d) there are three live consumers, all through the same public session API: the web visitor entry (internal/routes/public/sessions.go); the IM bridge — shipped 2026-08-24 (041285184, im-bridge/src/conversation.ts: issueSession + streamMessage from @standmeet/sdk-core, the same client microsites and embeds use, zero IM-specific admission logic), Telegram bot wired from the admin on 2026-09-04 (8c819f26d, backend/cmd/server/boot_im.go); and the visitor-side as-MCP handle (internal/routes/public/mcp_visitor.go). The job-loop side did not need a new entry: the access code auto-issued per application opens an ordinary visitor session that additionally exposes resume_read (2026-09-01, be45df09b, internal/routes/capload/capreg_resume_read.go) — the recruiter's agent is just another consumer.
The symmetry
Inward (visitor→agent) and outward (agent→world via connectors) both cross a neutral declared boundary — one design language for both directions.
- Inward seam: agent-as-injectable-driver (the launch handle)
- Outward seam: connector-plugins (the resolver and MCP adapter)
See also: agent-as-injectable-driver (launch abstraction); connector-plugins (connector binding).