Identity, Reliable Execution, and Intent Analysis of AI Agents
Andrew Green analyzes the challenges not yet fully solved in AI agent development.
The Great Challenges in AI Agent Development
In a blog post published by Andrew Green on the n8n blog on July 10, 2026, he details that after examining hundreds of tech docs from n8n, Google, Gumloop, and other platforms, he tallied 75 capabilities you’d expect an agent development tool to offer. However, he notes that there are many other aspects that can, need, or should be done with agents that were not included in the official technical report, and he shares some of them here. The core topics that are not yet fully solved in this field, according to him, are Agent Identity, Reliable Execution, and Intent Analysis.
Agent Identity
According to the article, AI agents have slipped between the cracks of human and non-human identities, which is problematic because there is currently no built-in way to keep track of agents, their actions, and their owners. If a certain agent decides to perform a mass deletion of data, identity is a tool that can help identify where it operates and who created it. Andrew Green notes that no one has solved the identity problem yet, and if anyone claims to have done so, it is usually by retrofitting existing techniques to agents, which does not really work. He emphasizes that the concept of Auth is in a better place than Identity, but Auth is only a subset of identity.
When running agents inside n8n, for example, there is no way to formally define the identity of the agent such that you give it a name badge, set policies for it, and monitor its activities within the wider environment it works in. Although you can integrate it with identity providers (IdPs) that support agents, it still requires independent engineering work on the part of the user.
The source details how to set up an n8n agent against Microsoft's Entra Agent ID system. The source lists the following components:
- A running n8n instance on Azure Container Apps, behind HTTPS ingress, including persistent Postgres storage 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 (token broker), and an on-behalf-of webhook communicating with the Microsoft Graph MCP Server for Enterprise.
- An active delegated MCP.User.Read.All call from inside the agent.
According to Andrew Green, the best option for running this natively as of today is the Google Gemini Enterprise Agent Platform, which represents a clear advantage of a broad cloud portfolio. According to Andrew Green, this platform provides a strongly attested, cryptographic identity for each agent. Through Agent Identity, agents can securely authenticate to MCP servers, cloud resources, endpoints, and other agents, acting either on their own behalf or on behalf of the end user. Agent Identity uses the agent's own credential and the Agent Identity auth manager. The 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.
Reliable Execution of Agents
Regarding reliable execution, Andrew Green explains that Large Language Models (LLMs) generate the code, and agents execute it. Just as a server can experience a temporary glitch and needs to be turned off and on again, agents can experience similar glitches. Many enterprises are feeling this pain, but Green notes that he sees very little systematic or deterministic approach to ensuring the reliable execution of agents. There is a selection of tools attempting to solve this problem, but their adoption is not fast.
The simplest thing that can execute agent code is a Python interpreter. However, an agent development tool is expected to do more than straight Python. The source lists the following components:
- Preventing the "confused deputy" problem: where sandboxes (such as MicroVMs or Wasm) can run untrusted AI code safely, or provide scoped network access.
- Durability: detecting failures, retrying steps, maintaining state, checkpointing, and validating outcomes.
- Concurrency: resource allocation and handling noisy neighbors as services scale.
Execution Durability and Concurrency
The article focuses in detail on the latter two aspects:
First, Agent execution durability – agents may hit rate limits from the LLM provider, experience request timeouts, or a self-hosted agent can run out of available memory. Execution durability can help recover from such incidents by: checking that agent tasks indeed get executed and completed steps are stored; if agents are interrupted, they start again from the exact same point they stopped; ensuring agents are executed once, not zero or multiple times; agent actions have time awareness such that they wait for other jobs to complete, schedules, and the like; and there is an option to go back and try again if the output does not yield a validated outcome.
Second, Concurrency management – agents and their underlying hosting environment compete for memory, CPU, and network calls. When agents share the same infrastructure (meaning they have no isolation), one resource-intensive session degrades the performance of all other sessions. 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, resource limits can be enforced per session at the kernel level via cgroups. Additionally, the real-time cluster state can be maintained for scheduling decisions. The isolation of sessions itself is performed through microVM or gVisor boundaries that prevent noisy neighbor resource bleed between agents.
At the execution layer, concurrency limits can be enforced on workflow execution and worker capacity, thereby preventing too many agent tasks from running simultaneously against a rate-limited LLM provider or external API. This is a backpressure mechanism 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 tool is useful for preventing LLM rate limit exhaustion, but it does not address underlying resource contention between different sessions.
Intent Analysis
Regarding intent analysis, Andrew Green notes that LLMs drift by design, and simple prompts like "please don't drift" or spinning up an orchestrator agent to ask it "please don't drift" will not help. Users will undoubtedly find themselves in situations where agents do not complete the assigned task, do something else, report complete on an incomplete job, or simply hallucinate results. Therefore, there is a need to monitor behavior drift to determine whether the agent's logic remains adequate for its scope and request. This monitoring requires continuously scanning conversations and code-level execution to see which libraries the agent wants to invoke, what the called functions will actually achieve, and what the LLM is doing with the operating system. The system tracks the reasoning field in the response and the tool call field in the response to understand every delegation of logic and the reasons for it. Green notes that while there is a lot of work in the security field to prevent prompt injections and confused deputy problems, very little work has been done to prevent non-malicious drift.
You can choose between LLM-based and non-LLM-based intent analysis:
LLM-based analysis systems are easy to implement and all-purpose. The downside is that the LLM-based judges suffer from the same problems they try to solve. Regardless, the source lists the following components as part of this analysis:
- An evaluation metric that examines the correctness and coherence of an agentic trajectory.
- An evaluation to measure 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 the agent toward the goal.
Non-LLM-based intent analysis systems are harder to implement and are characterized by the need for upfront thinking, a challenging task in a vibe-coding society. The source lists the following components as part of this analysis:
- Using encoder-only models, such as 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, the tools available, and whether the agent is allowed to spawn sub-agents.
Summary and Additional Report Findings
In summary, Andrew Green explains that in the second iteration of the technical report, the teams evaluated different tools against 75 capabilities, ranging from code execution and sandboxes to authentication and killswitches. Some of these features have become heavily commoditized, while others are clear differentiators. Additionally, the article notes that n8n users come from a wide range of backgrounds, experience levels, and interests. The blog team is interested in highlighting different users and their projects on the blog to inspire the community. In the original source, there is no mention of any local Israeli context.