Dashboards and query languages were translation layers that people used to reach the answers they actually wanted.
2
MCP connects agents to applications, but agents still struggle with memory, too many tools, and tasks that cross application boundaries.
3
Products need interfaces that let agents search for tools, form execution plans, and complete work across multiple applications.
Summary
Sarah Simionescu argues that dashboards are becoming less useful as agents take over the work of finding and combining information. She traces the shift from manually moving between Slack, Datadog, Sentry, VS Code, and GitHub, through AI query buttons, to MCP. MCP gives agents access to applications, but a large collection of isolated servers creates problems with memory, tool selection, and cross-application tasks. Composio's approach adds search and execution plans so an agent can select the tools it needs and understand dependencies between them. In the demos, Claude investigates a Slack bug across Slack, Sentry, Datadog, and a codebase, then drafts a pull request. It also combines PostHog and Metabase data without loading full results into context. Sarah ends by arguing that software companies now need to design for agents, which judge an application by whether it can complete a requested task.
Dashboards translated human questions into tool-specific queries
Sarah describes using Datadog every day for six months without opening its dashboard. When a coworker asks her to inspect an alert, she logs in and freezes because she does not know where anything is. Her normal workflow had involved reading Slack, writing a Datadog query, checking Sentry, fixing code in VS Code, and opening a GitHub pull request. Each application had its own interface and query language. Datadog had its syntax, Jira had JQL, and Slack had search modifiers. Even systems that used SQL could disagree about how SQL worked. Sarah says these dashboards and query languages were translation devices between people and data. People wanted the answer, not the dashboard.
AI query buttons removed some manual work without removing the underlying limits
In 2023, applications began adding a sparkle button that asked an LLM to write a query. Sarah says this could produce the answer with a click, provided the question did not require more than two database joins. The buttons spread across dashboards, making them appear AI-native. Her point is that this only moved the translation step from the user to a model. The model still had to generate a query for one application, and the approach did not solve tasks that involved several systems. MCP changed the interaction by allowing an agent such as Claude to generate and execute queries on the user's behalf, but the protocol left each service to decide how it would communicate with the agent.
MCP deployments fail when agents have no lasting memory
Sarah gives three problems with wiring together many MCP servers. First, agents do not learn from previous conversations. An agent that formatted Slack links incorrectly yesterday has no memory of that mistake today. Teams can add skills, but Sarah calls this a band-aid because more instructions also consume context. The result is an agent that receives more information while having less room to reason about the task. This makes repeated work dependent on the quality of the current prompt and the context supplied in that conversation. MCP provides a communication channel, but it does not by itself create a durable understanding of how an organization uses its tools.
Large tool collections make selection and dependency resolution harder
The second problem is the number of available tools. Sarah says that connecting enough servers can place thousands of tool definitions in the model's context window. She gives Composio's GitHub toolkit as an example, with more than 200 tools. The model can drown in this list, choose the wrong tool, or fail to work out which tool must be called first. A task often has dependencies, such as finding a Slack channel ID before searching its messages. Sarah's proposed interface searches for the tools needed for the stated task and returns a plan for using them, instead of exposing every possible operation at once.
The third problem is isolation. Each MCP server knows about its own application and has no view of the other systems involved in a task. Sarah describes agents as having doors into many applications while standing in separate rooms without a map. Her bug-fixing demo starts with a Slack message and asks Claude to use Sentry and Datadog, find the root cause, and draft a pull request. Composio Search identifies the required work, returns the appropriate tools and their usage plan, and lets Claude pull Slack context, query Datadog and Sentry in parallel, and scan the codebase. Sarah says the resulting pull request is ready in less than five minutes, without a custom workflow or skill.
An agent-oriented interface translates inconsistent APIs into usable operations
Sarah says Composio is building an interface for agents on top of MCP, CLI tools, and native tools. It translates APIs that are messy, sparsely documented, and frequently changing into operations that agents can use consistently. The aim is a unified experience across the applications people work in. She contrasts this with each application's native MCP server, referring to early unreleased comparisons using the same tasks and model. Her explanation for the difference is the extra layer of search, planning, and coordination. The agent is given a route through the task rather than a large catalogue of unrelated application functions.
Agents can combine data without placing full result sets in context
In the second demo, Sarah asks Claude to find the distribution of users' selected verticals during onboarding in PostHog. She then asks about the toolkits used by users who selected e-commerce. Claude queries PostHog for the relevant user IDs and saves the result without loading the full output into its context. It examines the Metabase schema and samples data before generating an SQL query through Composio Remote Workbench. The query searches for those IDs in Metabase, allowing Claude to compare data from both applications. Sarah says the result, showing the most popular toolkits for that user group, appears in less than a few minutes.
Software products now need to be usable by agents as well as people
Sarah says many companies are making websites friendly to AI search, while fewer are preparing their applications for agents. Composio began by turning popular applications into tools that agents could use, and Sarah says startups now receive requests from customers who want to access their services through agents. She describes agents as users without eyes who do not click a sparkle button. They arrive with a goal and a set of tools, then judge an application by whether it can complete the task. That changes product design. Interfaces need discoverable operations, useful dependencies, and ways to complete work across the systems involved.
