Kickside Agents

User agents for Kickside: the agent and tool registries, user-created agent components, the agent resolver and runner, a capability library, and a user-facing CRUD API.

What it provides

• Registries — kickside.agents:agents and kickside.agents:tools contract definitions (default bindings in kickside.agents.registry).
• User agents as components — the user_agent binding implements kickside.contract:component (status) and kickside.contract:deletable (cleanup); agents are stored as rows in the shared components table via kickside.component.
• Resolver — agent_resolver binds wippy.agent:resolver (default) so the runtime can load any user or built-in agent.
• Runner — projection worker that runs an agent turn and writes the reply back through kickside.connection.
• Traits — reusable agent capabilities (thread read/write, connection read/manage/admin, workspace, workflow runner, agent switch, attachments, inbox request, navigation).
• Registry discovery — built-in agent entries can be contributed by the app or any installed module via agent.gen1 registry entries.
• HTTP API — /user-agents CRUD + /agents/{list,traits,tools} discovery.

Requirements

• api_router (required ns.requirement) — a firewalled router the endpoints attach to. The handlers do no auth of their own.
• kickside.component — persistence and access-control service for user-owned agent components.

Boundary

Permission-agnostic: all authorization is enforced by the host router (token_auth + endpoint_firewall) and by the component service. Optional modules publish their own traits and tools instead of becoming dependencies of Agents. Automation is one such optional consumer: Agents exposes agent discovery and invocation contracts without depending on the Automation package.