StackA2A
·7 min read

Best A2A Agents for Enterprise Automation

Evaluating the top A2A agents for enterprise workflows: expense approval, travel planning, calendar scheduling, task management, and n8n integration.

a2aenterpriseautomationbest-of

Enterprise automation is where A2A makes the most obvious sense. You have discrete business processes -- expenses, travel, scheduling -- that already live in separate systems. A2A gives each one an agent, a standard interface, and the ability to call each other without custom integration work.

The ecosystem is still early. Most of these agents are demos or reference implementations. But the patterns they demonstrate are solid, and forking them for production use is straightforward.

Quick Comparison

Agent Framework Language Auth Best For
ADK Expense Reimbursement Google ADK Python None (demo) Approval workflow pattern
Travel Planner Agent Custom Python None (demo) Multi-step orchestration with dependencies
Google Calendar Agent Custom Go OAuth2 Real calendar integration
Elkar A2A Custom TypeScript None Managing other agents
N8n Agent Custom Go None Bridging to n8n workflows

ADK Expense Reimbursement

Repo: a2aproject/a2a-samples/adk_expense_reimbursement

The most useful thing about this agent is not expense reimbursement -- it is the multi-turn approval workflow pattern. Employee submits, agent validates against policy, routes for approval, tracks status. That state machine generalizes to purchase orders, access requests, time-off, anything with a submit-review-approve flow.

response = await client.send_message(
    message={
        "role": "user",
        "parts": [{
            "kind": "text",
            "text": "Submit expense: $450 for team dinner on Feb 15, category: meals"
        }]
    }
)
# Agent responds: "Please provide the receipt image or a brief justification."

Built on Google ADK. Official sample. The code is clean and well-documented enough to serve as a template. The main limitation: no real auth, no real policy engine. You are forking this and wiring in your own business rules, not deploying it as-is.

Travel Planner Agent

Repo: a2aproject/a2a-samples/travel_planner_agent

This is a reference for dependency-aware orchestration. Booking a hotel depends on knowing the flight arrival time. Ground transport depends on both. The Travel Planner decomposes a high-level request ("London next Tuesday, two-day conference") into ordered sub-tasks with constraints.

No real booking APIs are wired up. It is a demo. But the orchestration logic -- how it handles constraints, budget limits, preferences, and multi-turn modifications -- is the valuable part. That pattern applies to event planning, employee onboarding, supply chain coordination, or any workflow where step N depends on step N-1.

Google Calendar Agent

Repo: inference-gateway/google-calendar-agent

This one actually connects to a real API. OAuth2 against Google Calendar, written in Go, creates/updates/deletes events, finds available slots across calendars, handles recurring meetings. It is one of the few agents in the ecosystem that goes beyond demo into something you could actually deploy.

  • Real OAuth2 integration, not mocked
  • Go binary -- lightweight, easy to containerize
  • Registered on the Inference Gateway registry
  • Natural language queries: "What meetings do I have tomorrow?"

The catch: it is Google Calendar only. If your org is on Outlook/Exchange, you are writing your own. But the OAuth2 integration pattern it demonstrates is worth studying regardless.

Elkar A2A

Repo: elkar-ai/elkar-a2a

Elkar answers the question that comes up once you have three or four agents running: who manages them?

It is a task management system for agents. It assigns work, tracks completion, handles failures and retries, and gives you a web dashboard for human oversight. 147 GitHub stars suggest real adoption. TypeScript-based.

This is not an agent that does business logic. It is infrastructure. You need it once you are past the "two agents calling each other" stage and into "a fleet of agents processing real work." Without something like Elkar, you end up building ad-hoc monitoring for each agent, which does not scale.

N8n Agent

Repo: inference-gateway/n8n-agent

The pragmatic choice for teams already running n8n. Instead of rebuilding your existing 400+ n8n integrations as A2A agents, this agent wraps them. It can generate n8n workflow definitions from natural language, execute existing workflows via the n8n API, and report results.

Written in Go. The value proposition is simple: if you already have n8n workflows for Slack notifications, Jira ticket creation, email automation, etc., this agent lets other A2A agents trigger them. No migration required.

If you are not already on n8n, there is no reason to start here. Just build your agents directly.

Integration Patterns That Matter

Authentication

The Agent Card spec supports OAuth2, mTLS, and API keys via securitySchemes:

{
  "securitySchemes": {
    "oauth2": {
      "type": "oauth2",
      "flows": {
        "clientCredentials": {
          "tokenUrl": "https://auth.example.com/token",
          "scopes": { "agent:execute": "Execute agent tasks" }
        }
      }
    }
  }
}

For production: OAuth2 client credentials for service-to-service, mTLS within your network, API keys for internal agents behind a VPN. Most of the agents listed above ship with no auth. That is fine for evaluation but not for anything handling real data.

Multi-Turn Workflows

Enterprise processes almost always require back-and-forth. The A2A pattern: initial request, agent asks for missing info, caller provides it, agent executes, agent returns results or asks for approval. Each turn reuses the same task ID to maintain context. The Expense Reimbursement agent is the best reference for this.

Orchestrator Pattern

Coordinator Agent
  +-- Expense Agent (validates and routes)
  +-- Calendar Agent (blocks time)
  +-- Travel Agent (books flights/hotels)
  +-- Elkar (tracks all tasks)

The coordinator owns the business process. The specialists own their domains. All communication is A2A. This is the target architecture -- none of these agents implement it end-to-end yet, but the pieces are there.

See the full Enterprise Workflow stack on StackA2A for all available agents.

Related Stacks