A2A 1.0 · Ed25519 receipts · SOC 2 in progress
Build October 31, 2026Status
AgentDraft▸agentdraft.io
API key

What belongs in an audit trail for production agent jobs

Design an audit trail for production agent jobs that answers the questions that actually get asked: which agent acted, under what authority, and who approved it.

An audit trail for production agent jobs is an append-only sequence of immutable records that captures every state-changing operation alongside the acting identity, granted credential scope, explicit human authorization, and before-and-after resource state. If an autonomous agent alters state without emitting an audit record, the failure is a system bug rather than a routine logging gap.

When an agent operates in production, it runs code outside human visual inspection. It schedules calendar slots, sends outbound emails, provisions database records, and triggers payment transactions. If a customer questions why an appointment vanished or why an email left an agent inbox without human review, general application logs rarely provide the answer. Logs are optimized for transient debugging: developers sample them, rotate them every seven days, and frequently drop critical payload fields. An audit trail exists for attribution, forensic investigation, and regulatory reconstruction. It must withstand an audit inquiry six months after an incident occurs.

A defensible audit trail requires strict mechanical guarantees: cryptographic verification, deterministic correlation identifiers, and strict separation between transient debugging streams and permanent state transitions. Building that architecture requires treating the audit record as an explicit data model rather than an afterthought of your execution framework.

The audit record is the unit of design, not the log line

Engineering teams frequently attempt to satisfy compliance and operational review by aggregating stdout console logs into an OpenTelemetry collector or Elasticsearch index. This approach fails during production postmortems. Application logs record internal execution flow: function entries, stack traces, LLM token usage, and latency counters. Teams rotate, sample, and mutate these logs when storage costs escalate.

By contrast, an audit record represents a discrete historical transaction. It is immutable, append-only, and comprehensive. Every state mutation must yield exactly one audit record containing four core operational facts:

  • The permanent machine identifier of the agent combined with the specific cryptographic key identifier that authenticated the request.
  • The exact mutation operation performed alongside the uniform resource identifier of the target entity.
  • The specific credential scope evaluated by the receiving API and the unique approval gate identifier if the action required human clearance.
  • The authoritative server-side timestamp generated by the database or storage layer, discarding client-reported clock values.

Treating the audit record as the unit of design changes error handling. If a database transaction commits an operational change but fails to write the associated audit entry, the entire transaction must abort. If an external API updates an external calendar or mailbox without writing a corresponding audit record, the integration violates system invariants. Architectural guidance in the OWASP Logging Cheat Sheet emphasizes that audit events require strict immutability, complete contextual attribution, and total separation from transient debug streams. Designing an audit trail for production agent jobs means building an infrastructure where an unrecorded state mutation is treated with the same severity as data corruption.

Which agent did it: identity that survives key rotation

Attribution in autonomous systems breaks down when teams identify agents by volatile attributes. Logging an agent's self-reported name or its framework-level label (such as SchedulingWorkerAssistant) creates ambiguity. In frameworks like LangChain, CrewAI, or AutoGen, developers frequently rename, clone, or instantiate transient worker agents on the fly. The audit record must store the immutable agent_id generated at creation time, which remains constant across renames and redeployments.

Cryptographic key attribution requires equal rigor. Production agents interact with infrastructure APIs using bearer API keys. In secure environments, keys prefixed with identifiers like avs_live_ are hashed upon creation using memory-hard password hashing algorithms. As detailed in the OWASP Password Storage Cheat Sheet, algorithms such as Argon2id provide strong resistance against GPU-accelerated brute-force attacks by requiring configurable memory allocation, computational iterations, and parallelism threads. Because the API stores only the Argon2id hash, the raw bearer token cannot be recovered from the database after initialization.

If an audit system logs only the raw API token, it creates a severe security vulnerability. If it logs a generic message stating "Authenticated via API Key," attribution becomes impossible once a key is rotated. The audit entry must capture a distinct, non-sensitive key_id (for example, key_01J8Z4M9PQR7). When an agent key is rotated or revoked following a suspected credential leak, an auditor can query historical transactions by key_id and trace every mutation that specific credential authorized before its revocation.

Furthermore, the record must capture the specific credential scope used to authorize the endpoint call. Key authorization models typically assign fine-grained permissions per credential, such as availability:read, bookings:write, mailbox:read, mailbox:write, rules:read, and approvals:request. When an agent provisions a calendar hold, the audit trail should not merely record that the key was valid. It must log scope_used: "bookings:write". Recording the exact scope allows teams to detect credential creep and privilege escalation. For instance, if an agent key configured only for availability:read and bookings:write attempts an operation requiring approvals:request, the rejection event and the mismatched scope provide clear evidence of agent misconfiguration or prompt injection.

Who approved it: linking the gate to the action

Autonomous agents operating in high-consequence domains must pause before executing destructive or commitments-heavy tasks. A complete audit trail must preserve the unbroken provenance chain between an agent's intent, the human intervention, and the final execution. The primary failure mode in human-in-the-loop agent workflows is the "orphaned approval": a log entry indicating an action occurred, alongside a disconnected chat message where a human said "looks good," with no programmatic link between the two.

An audit-grade human approval workflow operates through explicit state machines. When an agent encounters an action requiring human sign-off, it opens a formal approval request via an API endpoint. The request includes a human-readable one-line summary and a structured JSON evidence payload describing the planned parameters (such as recipient email, proposed calendar invitees, or refund amounts). The system assigns this request a persistent approval_id.

The human review must happen within an authenticated environment. Approvals are decided in the AgentDraft dashboard. AgentDraft emails the workspace owner a notification linking to the queue, but the decision itself is made signed in—there are deliberately no approve-from-email links, because an unauthenticated one-click approve is an attack surface. Slack, Discord, Teams, SMS and push delivery are not available today. When the reviewer signs in using a passkey compliant with the W3C Web Authentication specification or a verified bootstrap link, they inspect the evidence payload and record a decision: APPROVED or REJECTED, accompanied by an optional operational note.

Every transition in an approval lifecycle emits an immutable audit record and triggers an associated webhook event. The final state-changing execution must reference the upstream approval_id. If an agent dispatches an outbound email or triggers a financial payout, the resulting execution record must contain the foreign key linking directly back to the resolved approval object.

Consider the architecture of generic external gates. The gated action does not have to be one AgentDraft performs—a deploy, a migration, or a refund is gated the same way. Every transition lands in the append-only audit trail and fires an approval.* webhook. For this reason, the audit record requires a generic, structured action definition rather than a rigid enum of proprietary endpoints. However, developers must understand the technical boundary: the requesting agent decides for itself when to open an approval request. AgentDraft does not yet provide a policy engine that auto-requires approval by action class, amount threshold, or role, and there are no escalation chains or multi-approver quorums—a single workspace human resolves each request. Your application-level schema should include an optional policy_id field now so that future policy-driven gating can be integrated without requiring a breaking database migration.

What the record must contain to answer an auditor six months later

Six months after an incident, team personnel have changed, execution logs have rotated away, and memory of the incident is gone. The audit trail must be self-contained. The schema below represents the minimum viable structure required to reconstruct an agent action under formal forensic examination:

{
  "record_id": "aud_01J9A8B7C6D5E4F3G2H1",
  "occurred_at": "2026-10-31T14:22:08.412951Z",
  "workspace_id": "wsp_99214a8b",
  "agent_id": "agt_77c2e01f",
  "key_id": "key_01J8Z4M9PQR7",
  "scope_used": "bookings:write",
  "operation": "calendar.booking.commit",
  "resource_type": "calendar_booking",
  "resource_id": "cbk_33d981aa",
  "request_id": "req_01J9A8B5M27X89AB01CD",
  "approval_id": "appr_8820fbc4",
  "decision": "APPROVED",
  "decided_by_user_id": "usr_44b39e21",
  "status_code": 200,
  "error_code": null,
  "request_body_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "metadata": {
    "slot_start": "2026-11-02T10:00:00Z",
    "duration_minutes": 30,
    "bucket_count": 6
  }
}

Three mechanical design choices in this schema ensure operational longevity:

Cryptographic request body hashing over raw payload retention

Logging full raw JSON payloads in an audit trail introduces compliance risk. Outbound emails and booking invitations contain personally identifiable information (PII), sensitive notes, or internal tokens. Storing raw message bodies in an audit table creates a secondary data store subject to data subject deletion requests, conflicting with the requirement that an audit log remain immutable.

Storing an unkeyed cryptographic hash, specifically the SHA-256 digest of the raw canonicalized request body, proves payload integrity without retaining sensitive text indefinitely. If a party later presents a disputed email payload or contract parameter, hashing the disputed content immediately proves whether it matches the exact bytes the agent submitted.

Explicit capture of validation failures and operational rejections

An audit trail that captures only successful operations (HTTP 200 and 201 responses) cannot answer forensic questions about agent malfunction or prompt runaway. An auditor investigating an agent that flooded a booking gateway needs to verify whether the agent attempted to monopolize calendar resources and how the system rejected it.

For example, if an agent requests a 12-hour booking block that exceeds platform limits, the API rejects the request with an HTTP 422 and the error string booking_too_long. The underlying conflict engine enforces this restriction based on infrastructure limits. In transactional engines like Amazon DynamoDB, atomic batch writes are governed by strict operational limits. As documented in the Amazon DynamoDB TransactWriteItems API Reference, a single transactional write request is capped at 100 items. Because reservation engines reserve time across granular buckets, a calendar API writing atomic bucket rows must constrain maximum durations to stay below this limit. If an agent attempts to write more than 99 five-minute buckets in a single transaction, the rejection must be permanently logged in the audit trail. Logging the 422 status code, the booking_too_long error code, and the request_id provides concrete proof that the safety boundaries held.

The uniform correlation identifier

Distributed tracing requires a single identifier that stitches disparate operational logs together. The request_id must be established at the edge API gateway and propagated downstream across every subsystem: the audit table, the outbound webhook payload, and the approval record. Correlating logs using timestamps alone fails under high concurrency, as clock skew across distributed servers and asynchronous task queues make exact ordering unreliable.

Agent execution logs are not the audit trail (and why teams conflate them)

Teams building on frameworks like LangChain, CrewAI, and OpenAI Agents SDK often treat LLM execution traces as their audit system. They monitor LangSmith, Phoenix, or OpenInference dashboards, assuming that capturing every model thought, prompt string, intermediate tool call, and retry loop satisfies compliance.

Agent execution logs and audit trails serve distinct architectural purposes. Comparing their engineering characteristics highlights why they cannot be merged:

  • Execution traces generate massive data volumes. An autonomous agent executing a complex task may consume 40 reasoning steps, 25 vector database retrievals, and 8 transient tool calls to produce a single real-world outcome. Recording full prompt context for all 40 steps produces megabytes of log text per run. An audit trail captures only the discrete, state-changing mutations: the hold reservation, the commit, the approval request, and the external dispatch.
  • Retention schedules diverge because agent execution logs require heavy storage. Platforms sample them under load and rotate them over short intervals (typically 7 to 30 days). An audit trail avoids sampling entirely. Every valid mutation persists across the full retention window mandated by regulatory and business requirements.
  • Data privacy rules demand distinct storage boundaries. Reasoning traces often contain sensitive user inputs, intermediate system prompts, and transient PII extracted from unstructured sources. An audit record captures clean, structured references: resource IDs, actor IDs, timestamps, and hashes.

A classic failure mode occurs when a team relies on standard console output during a failure. An agent encounters an intermittent network timeout while calling an email delivery API. The agent framework retries three times. Simultaneously, an operator watching the failure from an internal dashboard clicks a manual resend button. The recipient receives duplicate messages with conflicting booking times. When the postmortem team investigates, the console logs show overlapping API calls with no clear attribution. Without a dedicated audit record tracking key IDs, approval IDs, and distinct request hashes, engineering cannot answer who approved agent actions and whether the rogue send originated from an automated agent retry or an uncoordinated human intervention.

Retention, immutability, and the read-path check

An audit trail must be append-only. The underlying storage layer must not expose UPDATE or DELETE interfaces to the agent or application runtime. If an administrative correction is necessary, such as marking a disputed booking as invalidated, the operation must be modeled as an entirely new append-only audit event containing a supersedes_id reference linking back to the original record.

Retention management introduces subtle legal and technical challenges. In distributed databases, TTL-based deletion is inherently lazy. When an item's TTL expires in DynamoDB or Cassandra, the database marks the item for garbage collection, but the raw data may persist on disk and appear in query scans for up to 48 hours before physical eviction. If an API contract specifies a 7-day retention period, an auditor executing a read query on day eight must not receive expired records simply because the background compactor has not run.

To provide consistent guarantees, retention limits must be enforced on the read path as well as the write path:

// Example read-path retention enforcement logic
function queryAuditRecords(workspaceId, requestedStartTime, retentionDays) {
    const now = getAuthoritativeServerTime();
    const retentionCutoff = now.subtract(retentionDays, 'days');
    
    // Clamp query start time to the strict retention boundary
    const effectiveStartTime = requestedStartTime.isBefore(retentionCutoff) 
        ? retentionCutoff 
        : requestedStartTime;

    const query = db.table("audit_records")
        .where("workspace_id", "==", workspaceId)
        .where("occurred_at", ">=", effectiveStartTime)
        .orderBy("occurred_at", "asc");

    return query.execute();
}

Applying an explicit cutoff condition in every read query guarantees that queries return identical, compliant datasets regardless of underlying storage compaction schedules.

Engineering teams must also maintain transparency regarding formal compliance claims. AgentDraft does not hold formal compliance certifications (SOC 2, HIPAA, ISO 27001, etc.). It does keep an append-only audit trail. Formal certifications require extensive organizational controls, third-party attestation, and operational audits that extend far beyond API mechanics. Building on an API with an immutable audit log gives you the technical primitive required to capture execution history, but your organization remains responsible for meeting its own compliance frameworks.

Retention capacity must align with regulatory timelines. For example, a 7-day audit retention window allows engineering teams to diagnose weekly production regressions and verify agent tool integrations. However, satisfying annual enterprise risk reviews requires retaining logs across several quarters. Platform engineers must choose infrastructure tiers whose retention horizons match their specific auditing obligations.

Verifying the trail: webhook signatures and replay windows

In autonomous agent architectures, internal state stores are frequently populated via asynchronous webhooks dispatched by orchestration engines and coordination APIs. If an agent infrastructure platform notifies your backend that a human approved a wire transfer or that a calendar hold was committed, your webhook receiver updates internal databases and audit tables.

This architectural boundary represents a serious vulnerability. If your webhook consumer appends entries to your internal audit database before cryptographically validating the incoming payload, an attacker can forge approval events simply by issuing raw HTTP POST requests to your public endpoint. The downstream audit log becomes compromised by unverified writes.

To prevent this, every inbound delivery must be validated using cryptographic message authentication codes (HMAC). Platforms compute signatures using a shared workspace secret over the raw payload and a timestamp. As standardized in cryptographic specifications such as RFC 6234, HMAC algorithms (including HMAC-SHA256) provide verifiable data integrity and authenticity. In AgentDraft, every webhook delivery includes the X-AgentDraft-Signature header:

X-AgentDraft-Signature: t=1761920528,v1=4f9b8c2d1e0a3f5b...

The signature string combines two key components: the Unix timestamp (in seconds) of transmission (t) and the hexadecimal HMAC-SHA256 signature (v1). The signature is computed over the string <t>. concatenated with the exact raw HTTP request body bytes.

Webhook consumers must execute two validation steps before persisting any record:

  1. Recompute and verify the HMAC: generate the HMAC-SHA256 hash using the local workspace signing secret and verify that it matches the v1 value using constant-time string comparison to prevent timing attacks.
  2. Enforce the replay window: parse the timestamp t and compare it to the current server clock. The receiver should reject any delivery where the timestamp deviates by more than 300 seconds (5 minutes).

The receiver must enforce this 300-second window locally. The issuing API signs the timestamp at dispatch, but only the receiving server can verify that the message was received promptly and not captured and replayed by a malicious intermediary. Rejecting stale timestamps blocks replay attacks. Signed webhook delivery is available on every plan, including the free Developer tier, enabling developers to build and test end-to-end verification logic in development sandboxes prior to production deployment. For implementation details, reference the AgentDraft webhook documentation.

A worked sequence: from agent intent to auditable outcome

To see how these primitives operate in a live system, consider an autonomous executive assistant agent tasked with coordinating a 30-minute customer meeting and sending an email confirmation. The agent must reserve time on a shared calendar, secure human sign-off for the email copy, and dispatch the message. The entire workflow must yield a verifiable, continuous audit trail.

Step 1: Reserving a race-safe hold

Two agents operating concurrently might attempt to book the same client availability window. To avoid double-booking, the agent does not immediately create a firm calendar event. Instead, it places a temporary hold on the desired slot.

The underlying coordination API locks time using fine-grained increments. AgentDraft's conflict engine locks time in five-minute buckets: a 30-minute booking writes 6 bucket rows, and the 480-minute maximum booking spans 96. The agent submits a hold request, which writes six bucket rows in the database under an atomic hold transaction. The hold carries a strict time-to-live (TTL) of 30 seconds by default. The system emits an audit record:

{
  "record_id": "aud_01J9B01AA",
  "occurred_at": "2026-10-31T15:00:00.102Z",
  "agent_id": "agt_77c2e01f",
  "key_id": "key_01J8Z4M9PQR7",
  "scope_used": "bookings:write",
  "operation": "calendar.hold.create",
  "resource_id": "hld_994812",
  "request_id": "req_001",
  "status_code": 201,
  "metadata": { "ttl_seconds": 30, "buckets": 6 }
}

Step 2: Committing the booking

Before the 30-second TTL expires, the agent converts the hold into a committed booking. In multi-agent environments, priority rules govern whether an incoming agent can displace an existing reservation. In AgentDraft, holds expire after 30 seconds by default. A committed booking can be bumped by a higher-priority agent only within a 30-second window, after which it is frozen. Once this 30-second window passes, the booking becomes permanently locked against preemption. The commit transaction succeeds and records the operation:

{
  "record_id": "aud_01J9B01DD",
  "occurred_at": "2026-10-31T15:00:12.441Z",
  "agent_id": "agt_77c2e01f",
  "key_id": "key_01J8Z4M9PQR7",
  "scope_used": "bookings:write",
  "operation": "calendar.booking.commit",
  "resource_id": "cbk_441029",
  "request_id": "req_002",
  "status_code": 200,
  "metadata": { "bump_window_seconds": 30, "frozen_at": "2026-10-31T15:00:42.441Z" }
}

Capturing the bump window and freeze timestamp directly in the audit record settles downstream scheduling disputes. If a secondary agent attempts to book the same slot at 15:00:50Z and fails, the historical record proves that the initial booking had already passed its 30-second window and could not be evicted.

Step 3: Opening an approval request

The agent must now dispatch a confirmation email containing calendar invite details. Because sending unvetted external communications carries operational risk, the agent pauses. Using a key granted the approvals:request scope, it opens an approval request via the API, attaching the proposed text and recipient details inside the evidence JSON payload. The API generates an approval_id (appr_5512a) and sets the state to PENDING.

Step 4: Human review and signed dispatch

The workspace human signs into the dashboard, reviews the proposed email text against the booking metadata, and marks the request as APPROVED. The dashboard records the decision and fires an approval.approved webhook to the application backend. The webhook carries an X-AgentDraft-Signature header, which the backend verifies before proceeding.

The agent reads the approval state and calls the mailbox endpoint to dispatch the message. The email leaves via an addressable agent mailbox. Blast radius isolation is critical here: an AgentDraft mailbox is an addressable inbox owned by one agent; giving each agent its own mailbox isolates blast radius, so one runaway agent exhausts its own quota rather than the whole sending domain. Mailboxes are counted per workspace, so per-agent isolation only goes as far as the plan's mailbox count. The dispatch operation writes the final audit record:

{
  "record_id": "aud_01J9B02ZZ",
  "occurred_at": "2026-10-31T15:02:18.910Z",
  "agent_id": "agt_77c2e01f",
  "key_id": "key_01J8Z4M9PQR7",
  "scope_used": "mailbox:write",
  "operation": "mailbox.message.send",
  "resource_id": "msg_009182",
  "request_id": "req_005",
  "approval_id": "appr_5512a",
  "decision": "APPROVED",
  "decided_by_user_id": "usr_44b39e21",
  "status_code": 200,
  "request_body_sha256": "8a3e7b2c...4f1"
}

Step 5: Automated trail reconciliation

An audit trail is only as reliable as its reconciliation checks. Every night, an automated verification job should query your state tables and match them against the audit log using SQL:

-- Nightly reconciliation query: detect unrecorded state mutations
SELECT 
    m.message_id,
    m.dispatched_at,
    m.request_id
FROM mailbox_messages m
LEFT JOIN audit_records a 
    ON m.request_id = a.request_id 
    AND a.operation = 'mailbox.message.send'
WHERE m.dispatched_at >= NOW() - INTERVAL '24 HOURS'
  AND a.record_id IS NULL;

If this query returns any rows, your system has an operational leak: an external message was sent without an accompanying audit record. Engineering teams should page on any reconciliation drift immediately.

Checklist before you call the trail production-ready

Before launching autonomous agents that mutate external systems, verify your audit trail implementation against these concrete criteria:

  • Every state-changing API endpoint emits exactly one immutable audit entry, verified by an automated integration test asserting record emission per operation.
  • Key attribution uses internal key_id identifiers and immutable agent_id values without logging plain API tokens or transient agent display names.
  • Audit records explicitly document the specific scope_used to pass endpoint authorization checks.
  • All timestamps reflect authoritative server-side storage clocks; client-provided timestamps are relegated to untrusted metadata fields.
  • Human approval gates capture the approval_id, reviewer user ID, explicit decision (APPROVED/REJECTED), and reviewer notes directly within the execution record.
  • Failed operations and input rejections (such as HTTP 422 booking_too_long) are logged alongside successful transactions.
  • Webhook receivers verify incoming HMAC-SHA256 signatures and enforce a maximum 300-second timestamp drift before processing records.
  • The audit query interface enforces retention window boundaries on the read path, preventing uncollected stale records from appearing in audit extracts.
  • An automated reconciliation job cross-references database mutations against audit logs daily and alerts on discrepancies.

Frequently asked questions

What orchestration tools provide comprehensive audit trails showing who executed modified or approved production jobs?

Most popular agent orchestration frameworks (such as LangChain, CrewAI, and AutoGen) do not provide native, immutable audit trails out of the box. These frameworks focus on orchestration logic, prompting, and local execution flow. While they integrate with tracing platforms to log execution traces, those traces are designed for debugging rather than regulatory compliance. Capturing an immutable audit trail requires routing state-changing operations through dedicated infrastructure APIs—such as AgentDraft for scheduling, mailboxes, and approval gates—or implementing append-only database ledgers that explicitly record identity, scopes, and approval decisions.

What is the difference between an audit trail and agent execution logs?

Agent execution logs capture the internal mechanics of an LLM workflow: prompts, intermediate token generations, chain-of-thought traces, tool-call parameters, and retries. They are high-volume, ephemeral, often sampled, and frequently rotated over 7 to 30 days due to storage costs. An audit trail records only completed, state-changing mutations (e.g., booking commits, message dispatches, database writes). Audit records are low-volume, strictly append-only, unsampled, and maintained across multi-year retention horizons to prove authorization, attribution, and outcome integrity to external auditors.

How long should I retain an audit trail for production agent jobs?

Retention requirements depend on the contractual and regulatory obligations of your operational domain. For internal developer sandboxes, a 7-day retention window is sufficient to debug tool calls and verify integration behavior. For production environments touching customer data, contracts, or financial commitments, retention periods typically span 90 days to several years. Choose an infrastructure plan that guarantees retention enforcement on both the read and write paths for the duration your compliance policies require.

Can an agent approve its own action?

No. Permitting an autonomous agent to approve its own consequential actions negates the safety guarantees of a human-in-the-loop gate. In a secure architecture, approval endpoints require human authentication. For example, in AgentDraft, approvals are resolved by a verified human within the dashboard authenticated via passkeys (WebAuthn). While an agent holds credentials to open an approval request using the approvals:request scope, it possesses neither the credentials nor the dashboard session required to resolve that request.

What should an audit record contain when an action is rejected?

A rejection audit record must contain the identical attribution fields as a success record: the server-side timestamp, agent_id, key_id, scope_used, and request_id. In addition, it must capture the HTTP failure status code (such as 403 Forbidden or 422 Unprocessable Entity), the specific error string (such as booking_too_long or insufficient_scope), and the SHA-256 hash of the rejected request payload. Capturing rejections allows security teams to detect runaway loops, permission misconfigurations, and attempted prompt injection attacks.

To inspect endpoint schemas, condition expressions, and record structures, review the AgentDraft API documentation. To begin testing audit trail reconciliation against real agent executions, review our tiers at https://agentdraft.io/pricing. AgentDraft's free Developer tier needs no card and includes 1 user, 3 agents, one mailbox per workspace (the owner moves it between agents), 50 bookings a month, 7-day audit retention, and booking-linked outbound email only (5 a day). Per-agent inboxes for more than one agent need a paid plan: Individual has 1 mailbox, Team 5, Scale 25, Enterprise unlimited (see agentdraft.io/pricing).