Deciding what an agent should do, not just what it can

A GoodBarber app can now be operated using any AI client like Claude, Cursor, VS Code, Codex, or Gemini. An MCP server manages the platform's operations, allowing the assistant to connect, authenticate, and perform tasks such as reading a catalog, publishing an article, or sending notifications. Pierre-Laurent explained the inner workings of this server.

Once it is established and functioning, the question arises of where to begin utilizing it. To address this, a public repository of markdown files has been created, with each file representing a specific usage scenario. These scenarios include tasks such as identifying best buyers, preparing winback campaigns for subscriptions nearing expiration, publishing articles, and scheduling them for a specific day.

These examples are not mere documentation of available APIs; instead, they present intentions and sequences that guide the assistant in carrying out desired tasks. Each scenario consists of a goal, a sequence of API calls, the desired shape of the resulting report, and guardrails outlining necessary actions. Importantly, every scenario points to one or more neighboring scenarios, creating a logical chain of operations.

This shift in approach moved the focus from merely cataloging API endpoints to defining how the platform should be used. A notable discovery during this process was the revelation of hidden rules governing user behavior. For instance, when notifying subscribers, the assistant must discern whether the request pertains to active subscribers or expired ones, a decision that must be explicitly stated rather than left to default options.

Writing these rules helped uncover underlying assumptions and provided clarity on the intended functionality. Additionally, the exercise highlighted the importance of avoiding premature conclusions in API interactions. An agent should search through multiple lists (such as prospects, active subscriptions, and expired subscriptions) before concluding and presenting results to the user.

Failing to do so may lead to incorrect assumptions and suboptimal outcomes. Furthermore, the scenario files emphasize the need for explicit confirmation when tasks involve uncertainty or ambiguity. Unlike standard training and evaluation methods that reward guessing, scenarios should instruct agents to thoroughly search for all possible matches before providing a definitive answer.

This approach ensures a higher level of accuracy and prevents misleading results. The repository also emphasizes the significance of documenting the silences or unaddressed aspects of an API. While an agent may receive acknowledgments and processing times for certain tasks, it does not provide information such as the number of recipients for notifications.

To ensure proper functioning, the repository includes explicit instructions for reporting incomplete or partial states. For example, if a paragraph fails during article publishing, the rule dictates that no automatic rollback should occur, and the assistant should clearly indicate what is missing for the user to proceed. This disciplined approach ensures transparency and enables users to actively manage and correct any issues encountered during the process.

Ultimately, these scenario files serve a dual purpose—they are both documentation for human understanding and code for agent execution. By combining these elements, the repository provides a comprehensive and interactive resource that empowers users to leverage the full potential of the platform.