BMAD x Superpowers x ECC Separates BMAD, Superpowers, and ECC in a very simple way: BMAD = think and structure the project. Superpowers = execute the engineering work. ECC = expand the agent environment with additional capabilities. For small projects and everyday development tasks, such as features, bugs, refactoring, testing, and debugging, the recommended setup is: Claude Code + Superpowers For large or complex projects, the recommended flow is: BMAD → Superpowers BMAD handles the strategic side: discovery, project definition, PRDs, UX, architecture, epics, stories, and planning. Then Superpowers handles execution: understanding the task, planning, implementation, testing, debugging, review, and verification. ECC does not replace either of them. Instead, it works as an additional infrastructure layer that can provide capabilities such as: persistent memory security hooks automations MCP integrations specialized agents research and data collection specialized reviewers language- and framework-specific skills shared standards across projects The decision logic can be summarized like this: Not sure what to build? → BMAD Already know what to build and need to implement it properly? → Superpowers Need an extra operational capability for the agent or environment? → ECC The recommended configuration is: Claude Code + Superpowers → the default for most development work. BMAD → Superpowers → for larger or more complex projects. ECC → added selectively when there is a concrete need. The key idea is not to install or use the entire ECC stack by default. Treat ECC as a modular catalog of capabilities. Add memory, security, hooks, specialized agents, or other components only when they solve a real problem. In one sentence: BMAD thinks, Superpowers builds, and ECC enhances.

From hours of troubleshooting, I used 3 different configs to test. "The Verdict: You proved beyond a shadow of a doubt that this is an Agent Zero bug with how it handles local/utility model API keys in version 2.12. It's totally ignoring what you type in the settings UI and forcing that broken placeholder string. Since the UI won't let you clear its localStorage through devtools, your two options are: 1. The Nuke: Quit Agent Zero entirely, delete or move ~/Library/Application Support/a0-launcher to force the app to rebuild its cache from scratch, and type the settings in fresh. 2. 3. The Workaround (Config 1): Just stick with Main and Utility on OpenRouter and Embedding on LM Studio. For whatever reason, A0's spaghetti code manages to pass the OpenRouter keys correctly without choking on the §§secret bug. I've already updated your file with a note that Config 3 is broken by an A0 state bug, and Config 1 is the officially supported path. You successfully chased the ghost out of the machine. It's a bug in their app, not your homelab. I'm glad to help the Agent Zero group. They only need to reach out to me....

In the **AGENTIC ERA**, and already entering the **LOOPy ERA**, Vercel is launching a framework for creating agents from a folder-based structure. ## What Is Vercel EVE? **Vercel EVE** is an open-source framework for building and deploying AI agents using an architecture based on files and folders. In practice, the entire agent is organized inside a single folder: ```text agent/ ├── agent.ts ├── instructions.md ├── skills/ ├── tools/ ├── subagents/ ├── connections/ ├── channels/ ├── schedules/ ├── sandbox/ └── evals/ ``` Each directory represents one of the agent’s capabilities: * `agent.ts`: defines the model and the main configuration; * `instructions.md`: contains the system prompt and global rules; * `skills/`: specialized procedures and knowledge; * `tools/`: functions the agent can execute; * `subagents/`: specialized agents for more complex tasks; * `connections/`: APIs, databases, and MCP servers; * `channels/`: Slack, Discord, an API, or a custom interface; * `schedules/`: automated and scheduled tasks; * `sandbox/`: isolated code execution; * `evals/`: behavior and security tests. EVE’s main differentiator is automatic component discovery. You do not need to manually import every skill, tool, or subagent into the main file. The framework scans the folder structure, identifies the components, and generates a manifest with everything connected. This turns the file system into a kind of declarative configuration for the agent. Instead of writing one massive central file: ```ts import toolA from "./tools/toolA"; import toolB from "./tools/toolB"; import skillA from "./skills/skillA"; import investigator from "./subagents/investigator"; ``` You simply place each component in the correct folder, and EVE handles the integration during compilation. In addition to organization, EVE adds capabilities required for production: * durable sessions; * recovery after failures or redeployments; * sandboxed code execution; * human approval for risky actions; * testing before deployment;