extra-org/extra

Thinking Task: Improve Tool Content in Human-in-the-Middle Context Today, when a tool requires Human-in-the-Middle approval, the content shown to the user is not always clear or useful enough. I would like us to think about what should be displayed there so the user can understand, in a simple and natural way, what the tool is about and what they are approving. The goal is not necessarily to expose all tool arguments or technical details. Goal Come up with a better, more human-friendly representation of a tool in the approval UI. It should be: Clear. Concise. Easy for a non-technical user to understand. Generic enough to work across different tools. Helpful for making an informed Approve / Deny decision. Open Question What is the right content and structure to show for a tool in Human-in-the-Middle? I’d like to hear different ideas and approaches before deciding on an implementation.

Context CLAUDE.md is explicit that the product/brand name is Extra; agent-engine/agent-manager are only the PyPI package and console-script names, never meant to be user-facing. Every runtime setting, though, is prefixed AGENT_ — AGENT_DB_BACKEND, AGENT_DB_URL, and now (from #94) the whole AGENT_AUTH_* family (AGENT_AUTH_MODE, AGENT_AUTH_SECRET, AGENT_AUTH_COOKIE, AGENT_AUTH_CLAIM_*, etc.). Why this is worth fixing Brand mismatch. An admin configuring "Extra" will reasonably look for EXTRA_*, not AGENT_* — the env-var surface leaks an internal package name into the one place customers actually type things. Collision risk in enterprise environments. "agent" is a heavily overloaded word in infra (monitoring agents, security agents, etc.). AGENT_AUTH_MODE sitting next to e.g. DATADOG_AGENT_* in a shared secrets manager or ConfigMap is genuinely easy to misread or collide with. Why it's not part of #94 #94 only adds new settings; it followed the AGENT_DB_* naming that already shipped