eve: AI agent without “plumbing” (and with a structure that fits in a folder)

Channels, connections, schedule, skills, and tools: the boring part becomes reusable infrastructure, while you focus on the agent's behavior. Building a "real" AI agent (the one that works in production, not a local demo) rarely fails due to the prompt. It fails because even before responding to the first user, a significant amount of repetitive infrastructure needs to be set up: entry channels, authentication with external services, secure runtime, scheduled jobs, crash management, and - especially when dealing with money - a human approval flow.

The point is that all of this is not your agent. It's the scaffolding that every agent ends up requiring. The problem: the "scaffolding" you carry with you forever.

Imagine a classic support agent: it responds to customers (in Slack, Discord, Teams...), consults the account and billing status, executes refunds when due, and sends a summary every morning. It seems linear until you try to implement it for real. Before the first response, you typically have to deal with: a complete Slack integration (token, signing secret, webhooks, event management), authentication with the billing provider (and secure credential management), a reliable execution environment where tools and logic can run, a scheduler (cron) for summaries, resilience: what happens if it "breaks" in the middle of a conversation?, and human-in-the-loop: no refund should be processed without review/approval.

This part is expensive, repetitive, and tends to multiply team by team and agent by agent. Eve's idea: the agent as a standard directory. Eve turns the approach upside down: instead of building the plumbing every time, it gives you a standard structure where the scaffolding is already provided, and your work focuses on what the agent must do. In practice, the agent becomes a folder with: instruction.md at the root, and five directories: channels/, connections/, schedules/, skills/, and tools/.

The choice is also interesting for those who do frontend and platforms: it's a "config-as-code" design, readable, versionable, reviewable via PR, and with clear boundaries between responsibilities. What each folder does (with concrete examples):

1) channels/: where users talk to the agent. Here, you define the points of contact. In a Slack scenario, the integration can be reduced to a single file, without having to manage tokens, signing secrets, or webhook code manually. The most practical thing is the extensibility: adding a new channel (Discord, Teams, Telegram, SMS) follows the same pattern - "one file per channel" - instead of a separate project with different conventions.

2) connections/: integrations and credentials, without exposing them to the model. Connections encapsulate access to external services (billing, CRM, ticketing) through interfaces like MCP or OpenAPI. The key advantage is the separation between: conversational model/context and credentials and real calls. In other words: the model does not "see" secrets, tokens, or keys. It's an architectural detail that reduces the attack surface and makes compliance more sustainable.

3) tools/: executable code, isolated. Tools are functions (for example, in TypeScript) for operations like "retrieve account", "calculate credit", "verify plan". Execution takes place in an isolated environment (sandbox), so that the code has clearer boundaries and limits what it can do in case of malicious input or bugs. For product developers: it's a clean way to transform "actions" into reliable, testable, and observable primitives.

4) schedules/: automations and cron without ad hoc infrastructure. The morning summary is a classic: it requires a cron, a job runner, separate deployments, and logging. With a schedule schema, this automation can become even a Markdown file with a cron expression at the top, and once deployed, it becomes a scheduled job in production.

5) skills/: policies and procedures that enter the context only when needed. "Skills" are operational instructions, policies, and procedures (often long) that the agent must follow: refunds, exceptions, escalation rules. Instead of dragging all policies into every chat turn, the approach is to load only the relevant skill into context when the conversation requires it.

Practical effect: lighter contexts, fewer wasted tokens, lower risk of confusion between rules, and more coherent behavior because the right procedure is "activated" at the right time.

Human-in-the-loop integrated: refunds with "Approve/Deny". When the agent can perform sensitive actions (e.g., refunds), it's not enough to say "ask for confirmation": a technical gate is needed. In the proposed model, the refund action is gated: if the user requests a refund in Slack, the agent does not proceed automatically. It stops in the thread and presents an explicit approval/denial action (buttons).

Only after approval is the tool executed for real. This is a substantial difference between "assistant" and "agent": the assistant suggests, the agent acts, but with robust guardrails.

Resilience: checkpointed workflows turn by turn. Real conversations are not linear: timeouts, network errors, approvals that arrive after minutes or hours, tools that fail. Each turn can be managed as a workflow with checkpoints. If something is interrupted in the middle, you don't have to manually rebuild the state: the flow restarts from the right point, even if the approval arrives much later. For a product team, this translates into fewer "edge cases" to chase and less orchestration code.

Observability: runs, tokens, and costs as part of the lifecycle. A often underrated theme: agents are not monitored only with generic logs. It's necessary to track: execution triggers, turns and passages, tokens in/out, and cost per run. Having this telemetry at hand makes it possible to optimize prompts/skills and make product decisions based on numbers (for example: which channels cost more, which requests generate more tool calls, where it's convenient to introduce caching or rules).