You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Loopworks' Eve agents currently ship with a fixed, narrow, auditable tool surface (agent/AGENTS.md: "keep prompt and workflow contracts typed and reviewable"; docs/prd.md Integration Requirements: "keep agent tools narrow and auditable"). There is no product surface today for operators or maintainers to extend agent capability per repo or per loop — for example, registering a custom tool, connecting an MCP server, or attaching an agent skill — the way Claude Code exposes tool creation, MCP servers, and Agent Skills to its own users.
This issue exists to track that gap so it isn't lost, not to prescribe the solution. It surfaced while scoping the chat integration epic (#53), where a natural next question was whether chat-originated agent behavior could be customized per team, and the answer was "not currently, and there's nowhere in the backlog tracking that this is missing."
Why this matters
As loop and agent scope grows (see the loop:development and loop:research agent issues, e.g. #13, #44-#51), teams will plausibly want to extend Eve without a change to the core agent runtime. Left untracked, this becomes an invisible ceiling on agent usefulness rather than a deliberate, governed decision.
Open Questions (for a future spike, not this issue)
Is customization opt-in per repo/loop manifest, or account-wide?
How does operator-supplied customization interact with "keep agent tools narrow and auditable" (agent/AGENTS.md)? Does it require a distinct, more restrictive contract than built-in tools?
Does an MCP-server connection model imply new credential/secrets handling beyond what .github/AGENTS.md and the observability redaction conventions (ADR 0003, persona test S04) already cover?
A decision is recorded (Proposed ADR or a follow-up scoped issue) on whether and how operators can register custom tools, connect MCP servers, or attach agent skills to Eve-run loops.
Any customization surface that ships preserves narrow/auditable tool contracts (agent/AGENTS.md) and goes through the agent evaluation framework (Agent evaluation framework #17) before it is default-on.
Security review considers the blast radius of operator-supplied tools/MCP servers/skills before this ships, consistent with the MVP security review precedent (MVP security review #16).
Notes
This is intentionally a discovery/backlog issue, not a committed implementation plan. Milestone M7 exists to hold this and any follow-on work; re-evaluate scope and priority once the questions above have answers.
Summary
Loopworks' Eve agents currently ship with a fixed, narrow, auditable tool surface (agent/AGENTS.md: "keep prompt and workflow contracts typed and reviewable"; docs/prd.md Integration Requirements: "keep agent tools narrow and auditable"). There is no product surface today for operators or maintainers to extend agent capability per repo or per loop — for example, registering a custom tool, connecting an MCP server, or attaching an agent skill — the way Claude Code exposes tool creation, MCP servers, and Agent Skills to its own users.
This issue exists to track that gap so it isn't lost, not to prescribe the solution. It surfaced while scoping the chat integration epic (#53), where a natural next question was whether chat-originated agent behavior could be customized per team, and the answer was "not currently, and there's nowhere in the backlog tracking that this is missing."
Why this matters
As loop and agent scope grows (see the loop:development and loop:research agent issues, e.g. #13, #44-#51), teams will plausibly want to extend Eve without a change to the core agent runtime. Left untracked, this becomes an invisible ceiling on agent usefulness rather than a deliberate, governed decision.
Open Questions (for a future spike, not this issue)
.github/AGENTS.mdand the observability redaction conventions (ADR 0003, persona test S04) already cover?Acceptance Criteria
Notes
This is intentionally a discovery/backlog issue, not a committed implementation plan. Milestone M7 exists to hold this and any follow-on work; re-evaluate scope and priority once the questions above have answers.