Agentic Integration Standard for ATS Platforms

The Problem

Recruitment businesses are adopting AI agents for CV parsing, candidate screening, interview summarisation, and workflow automation. But the systems of record — ATS/CRM platforms — remain locked behind manual browser interfaces with no programmatic access.

The result is that AI can process information outside the ATS, but can’t read from or write to the system where that information lives. This creates a gap: agents produce structured data, and humans then manually re-enter it into the ATS. The efficiency gain is lost at the point of entry.

This specification describes what ATS vendors need to provide for AI agents to interact with the platform as a system of record — without requiring access to, or knowledge of, the calling application.

---

Core Principle: Interface-Agnostic Access

The ATS vendor provides the interface. The agent builder chooses the tools. The recruitment business owns the data.

An ATS integration should not require the vendor to know how the data is used, what the calling application looks like, or which AI model is behind the request.

This is the same principle behind any well-designed API: the server provides endpoints, authentication, and data contracts. The client — whether it’s a web app, a mobile app, a Python script, Claude Code running in a terminal, or an autonomous AI agent — makes requests and receives responses.

What the ATS vendor must provide

• Authenticated programmatic access — the ability for an external system to read and write data via a defined interface
• Documented data contracts — clear schemas for entities (candidates, jobs, clients, activities)
• Scoped permissions — granular control over what an integration can access (read-only vs. read-write, entity-level permissions)
• Event notifications — the ability to notify external systems when data changes (webhooks or polling)

What the ATS vendor does NOT need to know

• Which AI model is making the request
• What the calling application looks like
• How the data will be processed or displayed
• Whether the caller is a human or an agent

---

Three Tiers of Agentic Access

Not every ATS needs to ship a full agentic framework on day one. There are three practical tiers, each progressively more useful for AI agents. Even Tier 1 unlocks meaningful automation.

Tier 1: REST API

Standard programmatic access via HTTP endpoints. The foundation that every modern SaaS platform should offer. Agents call endpoints directly using API keys or OAuth tokens.

• CRUD operations on all core entities
• JSON request/response format
• API key or OAuth 2.0 authentication
• Documented schemas and endpoints
• Pagination and filtering
• Rate limits of 100+ requests/minute
• Sandbox environment for testing

Tier 2: Webhooks + Events

Real-time notifications when data changes inside the ATS. Agents don’t need to poll — they react to events. This is what turns an API from “pull” to “push”.

• Event notifications on entity changes
• Configurable webhook URLs
• Event types: created, updated, deleted
• Payload includes changed entity data
• Retry logic for failed deliveries
• Event filtering by entity type
• Webhook signature verification

Tier 3: MCP Server

A Model Context Protocol server that exposes ATS capabilities as tools that AI models can discover and invoke natively. This is the future of agentic integration — the AI model understands what the ATS can do.

• MCP-compliant tool definitions
• AI-native tool discovery
• Structured input/output schemas
• Authentication via MCP auth flow
• SSE or stdio transport
• Works with Claude, GPT, or any MCP-compatible client
• No custom integration code needed

Why MCP Matters

The Model Context Protocol (MCP) is an open standard developed by Anthropic that lets AI models connect to external tools and data sources. Instead of writing custom API integration code for every ATS, an agent builder connects to the ATS’s MCP server and the AI model automatically discovers what it can do — create candidates, log activities, search jobs, and more.

Major platforms like Salesforce, Atlassian, Asana, Slack, and HubSpot have already shipped MCP servers. For ATS vendors, publishing an MCP server means any AI agent — regardless of which model or framework it uses — can interact with the platform without custom integration work.

For AgileX specifically, we test and develop integrations using Claude Code (a terminal-based development tool) or Python/Node scripts run from the command line. We do not require a visual interface, a browser, or a custom-built application. Our agents connect to the ATS via whichever interface the vendor provides — API, webhook, or MCP — and interact programmatically.

---

Data Entities: What Agents Need to Read & Write

The following entities represent the core data model of any recruitment ATS. An agentic integration must support CRUD operations on these entities at minimum.

Entity	Operations Required	Agent Use Cases
Candidates	Create, Read, Update, Search	CV parsing → profile creation, enrichment, deduplication
Jobs / Roles	Create, Read, Update, Search	Job spec ingestion, matching candidates to roles
Clients / Companies	Create, Read, Update, Search	Client record creation from emails/meetings, BD tracking
Activities / Notes	Create, Read, List by entity	Meeting transcription → structured notes, communication logging
Documents / Files	Upload, Download, List	CV upload, compliance documents, formatted CV output
Contacts	Create, Read, Update, Search	Client contact management, email capture
Placements	Create, Read, Update	Placement tracking, commission calculation triggers
Users	Read, List	Assigning records to consultants, audit trails

Activity Types Are Critical

In most recruitment businesses, activity logging is the single biggest administrative time drain. Every phone call, email, interview, client meeting, and candidate interaction should be logged as a structured activity on the relevant entity (candidate, client, or job).

An agentic integration must support creating activities with:

• Activity type — e.g. Candidate Communication, Client Feedback, Interview, CV Sent, Placement
• Summary text — concise description of the activity
• Description / body — detailed notes (can be AI-generated from transcripts)
• Entity links — associate the activity with a candidate, job, client, and/or contact
• Timestamp — when the activity occurred (not just when it was logged)
• Source attribution — flag whether the activity was logged by a human or an agent

Search Must Be Programmable

Agents need to find records before they can update them. The API must support search across all core entities by name, email, phone number, reference ID, and any custom fields. Search should return paginated results with sufficient detail to identify the correct record without opening the browser.

---

Interface Examples

Three practical examples showing how an AI agent would interact with an ATS across the integration tiers. These are tested from the terminal — no browser, no GUI.

Tier 1: REST API — Create a Candidate from Parsed CV

POST /api/v1/candidates
Authorization: Bearer {api_token}
Content-Type: application/json

{
  "first_name": "Thabo",
  "last_name": "Mokoena",
  "email": "thabo.m@email.co.za",
  "phone": "+27 82 555 1234",
  "current_title": "Senior Financial Analyst",
  "current_employer": "Nedbank",
  "location": { "city": "Johannesburg", "country": "ZA" },
  "source": "agent:agilex:ava",
  "tags": ["finance", "banking", "CA(SA)"]
}

// Response: 201 Created
{ "id": "cand_4821", "created_at": "2026-03-26T09:14:00Z" }

Tier 1: REST API — Log an Activity

POST /api/v1/activities
Authorization: Bearer {api_token}

{
  "type": "Candidate Communication",
  "summary": "Initial screening call completed",
  "description": "Candidate confirmed interest in Senior FA role at Discovery. Available from May. Salary expectation R85k-R95k pm. Willing to relocate to Sandton.",
  "candidate_id": "cand_4821",
  "job_id": "job_1205",
  "occurred_at": "2026-03-26T10:30:00Z",
  "source": "agent:agilex:grant"
}

Tier 3: MCP — Tool Definition for Candidate Creation

{
  "name": "create_candidate",
  "description": "Create a new candidate profile in the ATS from structured data. Returns the candidate ID and profile URL.",
  "inputSchema": {
    "type": "object",
    "required": ["first_name", "last_name", "email"],
    "properties": {
      "first_name": { "type": "string" },
      "last_name": { "type": "string" },
      "email": { "type": "string" },
      "phone": { "type": "string" },
      "current_title": { "type": "string" },
      "current_employer": { "type": "string" },
      "location_city": { "type": "string" },
      "source": { "type": "string" }
    }
  }
}

// The AI model discovers this tool automatically.
// No custom integration code required.
// Works with Claude, GPT, or any MCP-compatible client.

Testing From the Terminal

All of the above can be tested and validated from the command line using standard tools:

• curl / httpie — direct HTTP requests to REST APIs
• Python / Node scripts — automated test suites for API endpoints
• Claude Code — Anthropic’s terminal-based AI development tool, ideal for testing agentic workflows
• MCP Inspector — Anthropic’s tool for testing MCP server implementations

The ATS vendor does not need to provide a frontend, a visual dashboard, or a custom-built application for testing. A well-documented API and a sandbox environment are sufficient.

---

Vendor Landscape

A snapshot of how major ATS and recruitment CRM platforms compare on agentic integration readiness.

Vendor	Segment	REST API	Webhooks	MCP
Bullhorn	Enterprise ATS	Yes	Yes	Emerging
Lever	Mid-Market ATS	Yes	Yes	No
Greenhouse	Mid-Market ATS	Yes	Yes	No
Workday	Enterprise HCM	Yes	Limited	No
Zoho Recruit	SMB ATS	Yes	Yes	No
iCIMS	Enterprise ATS	Yes	Partial	No

The vendors above represent different ends of the market, but they share a common baseline: REST API access with documented endpoints. This is the minimum viable standard. Vendors without API access are asking their customers to choose between AI-driven efficiency and their existing system of record — a choice no recruitment business should have to make.

The MCP Opportunity for ATS Vendors

MCP adoption is accelerating across the SaaS ecosystem. Salesforce, Atlassian, HubSpot, Asana, Slack, and Shopify have all published MCP servers. For ATS vendors, this represents a significant competitive opportunity: the first recruitment-focused ATS to publish an MCP server will be the default integration target for every AI agent builder in the recruitment space.

Publishing an MCP server is not a massive engineering effort. In most cases, it’s a thin wrapper around an existing REST API that exposes endpoints as MCP-compatible tools with structured schemas. Anthropic provides open-source SDKs and documentation for building MCP servers in Python, TypeScript, and other languages.

---

What We Ask of ATS Vendors

This is not a feature request. This is an industry expectation. The recruitment sector is moving toward AI-augmented workflows, and the system of record must be accessible programmatically.

At minimum: REST API with documented endpoints

Ideally: Webhooks for real-time event notifications

Best practice: MCP Server for AI-native tool discovery

We build AI agents that automate recruitment workflows: CV parsing, candidate screening, interview summarisation, activity logging, communication capture, and performance reporting. Our agents interact with the ATS via whatever interface the vendor provides. We use Claude Code and terminal-based scripts to test and validate integrations.

We do not ask vendors to build custom integrations for us. We ask vendors to provide a standard, documented, authenticated interface to their platform — the same interface that any integration partner, internal developer, or automation tool would use.

The calling application is our concern. The data interface is yours.

---

Published by AgileX — agilex.co.za — March 2026