#56 — Ability to manage agents like staff
I want this to be a practice management tool of the future where people can connect their agents from other tools into here where we can manage ai agents in the same place as staff. please plan for this
3 Comments
Sign in to comment
·about 2 months agoAgent A — plan delivered (the ask was to plan, not build). Moving to Under Review for Daniel.
Full design: docs/product/agents-as-staff-plan.md on PR https://github.com/Firmary/firmary-os/pull/33 (docs-only). The one-paragraph version:
An agent becomes a real staff row (staff_users.kind='agent') with a Logto machine credential instead of a browser login — so the things you asked for fall out of machinery that already shipped: agents get custom roles from the frozen capability catalog (deny-by-default), segment scoping limits which clients they can even see, every action lands in the audit trail under the agent's name, and they're managed on /staff/admin/staff next to humans (add / rotate credential / suspend). External tools' agents (Claude, ChatGPT, anything) connect INBOUND by holding a Firmary agent credential via the MCP server (#82) or public API (#84) — revoke the credential and the external tool goes dark. Safety posture: agents start read-only; writes arrive later as PROPOSE-ONLY (the agent's write becomes a pending task a human approves — dual attribution), which is also the concrete first mechanism for the #83 AI-guardrails epic. Direct writes become a deliberate per-module opt-in after that.
Decisions you need to make (detailed in the doc): D1 staff-row model vs separate agents table (rec: staff row); D2 add 'agent' to the audit actor_type enum (rec: yes); D3 read-only first, propose-only second (rec: yes); D4 do agents consume a seat / metered unit / free (ties to pricing #89); D5 call them "Agents" in the UI vs "Service accounts" (rec: Agents).
No code was written for this item; phases fold into #82/#83/#84 rather than adding a new track.
·about 2 months agoAgent A claiming this until completion or block. The ask is a PLAN ("please plan for this"), so the deliverable is a design document: AI agents as first-class managed principals — identity/authn (scoped tokens, MCP), authz via the existing capability+segment system, audit attribution, lifecycle managed on the same admin surface as staff, inbound external-agent connections, and phasing mapped onto the existing #82 (MCP) / #83 (guardrails) / #84 (public API) epics — plus the explicit decisions Daniel needs to make. No product code in this slice. Started: 2026-07-09 02:55 America/Chicago.
Migrated to https://github.com/Firmary/firmary-os/issues/360 during the 2026-08-23 GitHub migration (status corrections and full history carried over). Quackback is now the public user-feedback portal; internal tracking for this item continues on GitHub.