After spending the past couple of months looking at hundreds of tech docs from n8n, Google, Gumloop, and the rest, I tallied up 75 capabilities you’d expect an agent development tool to offer.
But there are so many more things you can, need, or should do to agents that weren’t easy or fair to be included in the report, so I’m sharing some of these here.
Agent Identity
Agents have clearly slipped between the cracks of human and non-human identities, which is problematic because there is no way to keep track of agents, their actions, and their owners. If Agent X decides to go on a data deletion spree, identity would be the thing that can help you identify where it lives and who created the monster.
But nobody solved identity yet, and if they claimed to do so, it’s by retrofitting existing techniques to agents, which doesn’t really work (note that Auth is in a better place than Identity, but auth is just a subset of identity).
Let’s assume you run agents in n8n. There’s no way to formally define the identity of an agent such that you give it a name badge, some policies, and monitor its activities within the wider environment it works in. You can integrate it with IdPs that support agents, but still need to engineer your way through it.
This resource details how it onboards an n8n agent to Microsoft’s Entra Agent ID. While it's behind a paywall, it says you need:
- A running n8n instance on Azure Container Apps, behind HTTPS ingress, with persistent Postgres and file storage.
- A Microsoft Entra Agent Identity Blueprint, an Agent Identity service principal, and an Agent User account
- n8n workflows to execute a Microsoft Graph call, an Auth Manager that brokers tokens, and an on-behalf-of webhook that talks to the Microsoft Graph MCP Server for Enterprise.
- A working MCP.User.Read.All delegated call from inside the agent.
The best option for running this natively as of today is using Google Gemini Enterprise Agent Platform, which is clearly the hyperscaler portfolio advantage. Agent Identity provides a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard. With Agent Identity, agents can securely authenticate to MCP servers, cloud resources, endpoints, and other agents, acting either on its own behalf or on behalf of an end user. Agent Identity uses the agent's own credential and Agent Identity auth manager. Auth manager can create and manage auth providers, which are the specific configurations used to acquire, manage, and secure API keys, OAuth client IDs, OAuth client secrets, and delegated end-user OAuth tokens.
But even Google’s approach (which is one of the most advanced ones at the moment) you can find some critiques, like their usage of SPIFFE. “While SPIFFE can technically provide agent identities, current Kubernetes implementations treat all replicas as identical—a fundamental mismatch with agents’ non-deterministic, context-dependent behavior that creates compliance and attribution gaps”.
Agent Reliable Execution
LLMs generate the code, agents execute it. And just as a server hiccups and you need to turn it off and on again, agents can hiccup too. All enterprises have been feeling this pain, but I see little to no systematic (or dare I say deterministic) approach to ensure agents execute reliably. There is a selection of tools that are tackling this problem, but adoption is slow.
The simplest thing that can execute agent code can be the Python interpreter. You should expect an agent development tool to do more than straight Python, which would be:
- Prevent confused deputy: where sandboxes (e.g. MicroVMs/Wasm) can run untrusted AI code safely, or provide scoped network access,
- Durability: detect failures, retry steps, maintain state, check point, validate outcomes
- Concurrency: resource allocation and handling noisy neighbors as services scale
We’ve briefly covered code execution and sandboxes in the report, so let’s look at the other two:
Agent execution durability - Agents may hit a rate limit from the LLM provider, have a request time out, or a self-hosted agent can run out of memory.
Execution durability can help recover from this sort of incidents by:
- Checking agent tasks get executed and completed steps are stored
- If agents are interrupted they start again from the same point
- They get executed once, not zero or multiple times
- Agent actions have time awareness such that they wait for other jobs to complete, schedules and such
- Can go back and try again if output is not validated
Concurrency - Agents and the underlying hosting environment compete for memory, CPU, and network calls. When agents share the same infrastructure (i.e. they don’t have isolation), one resource-intensive session degrades every other session. Effective concurrency management requires kernel-level quota enforcement, real-time scheduling across heterogeneous workloads, and backpressure mechanisms that prevent bursts of agent invocations from cascading into downstream failures.
To support concurrency at the infrastructure layer, you can enforce per-session resource limits at the kernel level via cgroups, maintain real-time cluster state for scheduling decisions, and isolate sessions through microVM or gVisor boundaries that prevent noisy neighbor bleed between agents.
At the execution layer, you can enforce concurrency limits on workflow execution and worker capacity, preventing too many agent tasks from running simultaneously against a rate-limited LLM or external API. This is backpressure at the workflow level, not resource isolation at the compute level.
Other concurrency controls include job queues, such as limiting how many instances of a step or function run in parallel. This is useful for preventing LLM rate limit exhaustion but does not address underlying resource contention between sessions.
Intent analysis
LLMs drift by design, and simply saying “pls don’t drift” or spinning up an orchestrator agent and asking it “pls don’t drift” won’t help.
You will undoubtedly end up with agents not completing the assigned task, doing something else, reporting complete on an incomplete job, or just hallucinating results.You need to monitor behavior drift to determine whether an agent’s logic remains adequate for its scope and request. This would entail continuously scanning conversations and the code level execution to see which libraries it wants to invoke, what the called functions would actually achieve, and what the LLM is doing with the operating system. It tracks the reasoning field in the response and the tool call field in the response to understand every delegation of logic and why it does it.
And while there’s a lot of work here in security to prevent against prompt injections and confused deputy problems, there is very little work for preventing non-malicious drift.
You can choose between LLM-based and non-LLM-based intent analysis.
LLM-based are easy to implement and all-purpose. The downside is that the LLM judges inherit the same problems they try to solve. Regardless, some of these include:
- Evaluation metric that measures the correctness and coherence of an agentic trajectory
- Evaluation for measuring shift in the user’s primary conversational goal or workflow during a session, relative to their initial stated intent.
- Evaluating how effectively each action advances toward the goal.
Non-LLM-based intent analysis is harder to implement and requires upfront thinking, a challenge in a vibe-coding society. It includes:
- Using encoder-only models, like BERT or ModernBERT, which understand text but do not generate it, and using them to output a binary Yes/No.
- Tracking (i.e. database writes) whether the agent successfully accomplished all of the user’s goals.
- Defining immutable scopes that force agent execution through a set of steps, which can be defined during the reasoning process or by an orchestrator agent.
- Defining task-specific boundaries, authority to conduct tasks, tools available, whether it can spawn sub-agents.
But what can agent dev tools do?
In our second iteration of the report, we evaluated tools against 75 capabilities, ranging from code execution and sandboxes to authentication and killswitches. Some features are heavily commoditized, while others are clear differentiators.