Antarious Documentation

Antarious is an AI-native operating platform for organisations that need to run a high volume of knowledge-work at speed, but cannot afford to give up human accountability to do so. At the centre of the platform is Freya — a persistent, memory-enabled AI agent who coordinates a team of specialist sub-agents across every function of your organisation. Freya is not a chatbot. She is a strategic operator who observes your data, proposes decisions, waits for a human to approve them, and then executes at machine speed while recording every step in an audit trail.

The platform was built on a simple thesis: most AI tools either automate too little to be transformative, or too much to be trusted. Antarious rejects that trade-off. The platform is designed so that every external action — every message sent, every budget committed, every policy brief issued, every report filed with a donor or regulator — passes through a configurable human approval gate before it leaves your organisation. Freya does the work. Humans stay accountable.

Three commitments, in order

Everything in the platform is derived from three commitments that are deliberately stated in priority order.

01 · AI-First, Not AI-Added. Antarious was not built by bolting a language model onto an existing SaaS product. The agent architecture, the memory layer, the approval workflows, and the audit trail were designed together, from a blank page, to support autonomous work under human supervision. This matters because it means the platform behaves consistently: the same governance rules apply to a marketing email, a ministerial briefing, and a field-team report.

02 · Human-in-the-Loop. Every external action passes through an approval gate. The gate is configurable — low-risk actions can be set to self-authorise, high-risk actions can be set to require multiple approvers — but the gate is always there, and the record of who approved what, and when, is preserved indefinitely. As confidence builds, organisations typically widen Freya's autonomy on specific action types. They almost never remove the approval architecture wholesale.

03 · Full Transparency. Every action Freya takes is attributable. Every output she generates shows its sources, its reasoning, and the approval chain that released it. The audit trail is not a forensic feature retrofitted under regulatory pressure — it is the primary output of the platform, and everything else is a consequence of it.

How Freya is structured

Freya is the orchestration layer. Underneath her sit specialist agents, each responsible for a narrow function. A content agent drafts copy. An analytics agent interprets performance. A compliance agent checks outputs against your policies. Freya does not do any of this directly — she routes work to the right specialists, assembles their output, applies quality controls, and then surfaces the finished artefact to a human approver.

The platform ships with three agent libraries, organised by sector:

• The GTM library — 13 business agents covering strategy, ICP research, competitor intelligence, copywriting, paid media, SEO, social, brand governance, outreach, analytics, forecasting, customer service, and voice. Aimed at commercial organisations running marketing, sales, and customer operations.
• The Government library — 8 agents covering policy intelligence, service-delivery monitoring, budget tracking, compliance, document generation, inter-departmental coordination, public communication, and strategic forecasting. Aimed at ministries, agencies, and public bodies.
• The NGO / Development library — 10 agents covering programme intelligence, M&E reporting, partner performance, field data, beneficiary analytics, loan monitoring, document drafting, compliance, forecasting, and psychometric profiling. Aimed at development organisations, humanitarian agencies, and mission-led lenders.

A deployment does not need every agent. Most organisations start with three to five and add more as they become comfortable with the approval cadence. Agent configuration is covered in detail in the Deployment and Configuration section.

What Antarious is not

The platform is frequently evaluated against tools it is not actually comparable to. To save time during procurement, here is what it is not.

It is not a chat interface. You will not spend your day typing prompts. Freya operates proactively on a cadence that you configure — the weekly brief, the morning alert queue, the quarterly forecast — and she surfaces work when it needs human attention.

It is not a workflow automation product like Zapier or n8n. Those products chain together deterministic steps across APIs. Antarious does the harder work: judgement. Freya is asked to draft a donor report, not to move a row between two spreadsheets.

It is not a chatbot for your end-users. Although customer-service and public-communication agents can be pointed outward, Freya's default posture is internal. She operates inside your organisation, on behalf of your team, under your governance rules.

It is not a consultancy engagement. The product is a platform, not a service. Implementation partners exist and can be engaged, but the platform is usable by a competent in-house team with the documentation provided in this library.

Where to read next

If you are a decision-maker or a governance lead, read The Human-in-the-Loop Architecture next — it explains exactly what requires approval and how the approval graph is constructed. If you are a technical lead, skip to the Platform Architecture section. If you are an operator in a specific sector, the Sector-Specific Guides will be more directly relevant than the foundational documents.

The Human-in-the-Loop (HITL) architecture is the single most important design decision in the Antarious platform. It is the mechanism that allows Freya to take autonomous action on behalf of an organisation without transferring legal, ethical, or operational accountability away from the humans who own that accountability today. This document explains how the architecture is constructed, what it requires of operators, and what it provides in return.

The founding principle

Every external action passes through a human approval gate. An action is "external" whenever its effect is visible outside the platform — a message sent, a budget committed, a report filed, a decision communicated, a record written to a CRM or a case management system. Internal actions — Freya reading data, drafting options, running analysis, querying memory — do not require approval, because they produce no external consequence.

Approval gates are not a speed bump. They are the place where organisational judgement is exercised and where accountability is recorded. An action that passes a gate becomes authorised work; an action that does not pass is either returned for revision or cancelled. Both outcomes are recorded with timestamp, approver identity, and rationale.

The approval graph

Approval is not a single step — it is a graph. Each action type has an approval path defined by the organisation during deployment. The path can be single-approver, sequential, parallel, conditional, or threshold-based.

• Single approver: one named role authorises the action. Typical for low-risk, frequent work.
• Sequential: approver A must approve before it moves to approver B. Typical where subject expertise and line-management sign-off are both required.
• Parallel: two or more approvers must each sign off, but in any order. Typical for cross-functional actions (e.g., a ministerial communication reviewed by policy and by comms simultaneously).
• Conditional routing: the path depends on the value of the action — a contract below £10,000 routes to a contracts officer, above that threshold routes to a director.
• Threshold-based escalation: if an approver has not responded within a configured window, the action escalates to a delegate or a senior role.

Approval graphs are configured in the admin console and are themselves versioned and auditable — so an auditor can see not only who approved a given action, but also what the approval graph was at the moment of approval.

Severity and routing

Antarious ships with a default severity model that distinguishes low, medium, high, and critical actions. Each severity level has sensible default routing, which organisations typically tune during deployment.

What Freya handles vs. what humans own

A common misconception is that HITL means "humans do the work and the AI helps." The opposite is true. Freya does the work. Humans direct, approve, and decide. The split is irreducible in some areas and configurable in others.

How confidence builds

Most organisations begin with narrower autonomy than they finally settle on. For the first four to eight weeks, approval gates are set tightly: almost every external output requires a human review, not because the team distrusts Freya, but because the team is building an intuition for where her outputs are reliably excellent and where they need friction.

As that intuition forms, approval graphs widen. Specific action types move from "always review" to "review exceptions only" to "auto-release within preset rules." Every change to the approval graph is itself recorded, so an auditor can trace not only individual decisions but the governance trajectory of the deployment as a whole.

When Freya refuses to act

Freya will not take certain actions even when a human has attempted to authorise them. These are encoded as hard stops and cannot be removed through configuration. They include actions that would violate the platform's compliance controls, that would evade the audit trail, that would bypass a regulatory requirement in a jurisdiction where the tenant is registered, or that would discriminate on a protected attribute in a way that violates Article 22 of UK/EU GDPR.

What the architecture gives you back

The point of the approval architecture is not that it slows things down — it is that it lets you move fast without losing control. A team operating Antarious with a properly configured approval graph can expect the following outcomes:

• Throughput several multiples higher than a non-AI baseline, because Freya does the drafting, analysis, and orchestration work that humans previously did end-to-end.
• Fewer escalations, because standard work moves through standard approvers, and only exceptions reach senior roles.
• A complete decision record — every action you took, every action you considered and rejected, every alternative Freya proposed — which is worth more than it sounds the first time you are asked to reconstruct a decision from two years ago.
• A governance surface that can be inspected by an internal auditor, an external auditor, a regulator, or a donor, without a manual forensic exercise.

The rest of this library describes the specifics: what the audit trail looks like, how to configure the approval graph, how to design role permissions, and how to map the controls to external standards (ISO 27001, UK/EU GDPR, NCSC). This document is the why. Everything else is the how.

Most AI products you have used are monolithic: one model, one prompt, one conversation. This works well for narrow questions and poorly for real work, where a single task usually touches half a dozen domains — tone of voice, factual accuracy, regulatory posture, commercial context, and historical memory. Antarious is built on a different model: a team of specialist agents, coordinated by Freya, each an expert at a narrow slice of work.

This document explains how the multi-agent architecture is structured, what each agent sees and does, how context is shared between them, and how they compose into the workflows that power daily operations.

The Freya Agent Loop

Before looking at the agents themselves, it helps to understand how Freya herself reasons. She operates on a six-step loop that applies to every significant piece of work.

Every action Freya proposes passes through this loop. The loop is observable — an operator can inspect what Freya saw, what she concluded, what alternatives she considered, and why she selected the one she surfaced. This is the reasoning equivalent of the audit trail.

Specialist agents

Specialist agents are narrow, composable, and stateless. A specialist agent does one thing — draft an email, classify a reply, detect an anomaly, generate a chart — and returns a structured output. Specialists do not talk directly to each other; they pass their output back up to Freya, who decides what to do with it.

This design has three consequences worth noting:

• Each agent can be improved independently. The M&E Report Generator can be upgraded without touching the Psychometric Profiler. This is impossible in monolithic AI products, where a change to one prompt affects every downstream behaviour.
• Each agent is individually auditable. The audit trail records which specialist contributed which part of a finished artefact, what its inputs were, and what its confidence score was.
• Agents can be selectively disabled. If your organisation does not want the Voice AI agent operational, it is simply switched off. Freya's planning loop will not assign work to it.

The GTM library (13 agents)

The GTM library is the longest-standing of the three and the most commonly deployed. It covers the full go-to-market surface from strategy to close.

The Government library (8 agents)

The Government library is designed for ministries, agencies, and public bodies. The agents are tuned for policy work, service delivery, and public communication under a regulatory and accountability regime.

• Policy Intelligence Agent — horizon-scans new policy, legislation, and regulation across specified jurisdictions and summarises implications for the department.
• Service Delivery Monitor — tracks operational KPIs across delivery units, surfaces anomalies, and generates early-warning alerts.
• Budget Tracker — monitors spend against allocation, forecasts end-of-year position, and surfaces variances.
• Compliance Sentinel — tracks the department's obligations against regulation and statutes; generates evidence portfolios for inspection.
• Document Generator — drafts briefings, Cabinet papers, consultation responses, and parliamentary question answers under a sign-off chain.
• Inter-Departmental Coordinator — maintains a map of cross-departmental dependencies and surfaces coordination risks.
• Public Communication Agent — drafts press releases, social content, and public-facing guidance with mandatory editorial and legal review.
• Strategic Forecasting Agent — scenario-models delivery, demand, and budget positions over 1–5 year horizons.

The NGO / Development library (10 agents)

The NGO library serves development organisations, humanitarian agencies, and mission-led lenders. The defining characteristic of these organisations is that they answer to donors, regulators, and beneficiaries simultaneously — the library is designed to keep all three constituencies visible at all times.

• Programme Intelligence Agent — surfaces programme-level performance patterns, logframe alignment, and divergence from theory of change.
• M&E Report Generator — ingests partner data and drafts donor-ready reports against the relevant log frame, with traceability to source data.
• Partner Performance Monitor — scores implementing partners against delivery, compliance, and reporting metrics.
• Field Data Analyst — cleans and interprets submissions from ODK, KoBo, SurveyCTO, CommCare, DHIS2, and similar platforms.
• Beneficiary Analytics Agent — aggregates anonymised beneficiary data, identifies cohorts at risk of dropout, and surfaces equity gaps.
• Loan Portfolio Monitor — for mission-led lenders: tracks portfolio health, arrears, and early-warning indicators.
• Document Drafting Agent — concept notes, proposals, MoUs, case studies under a reviewer chain.
• Compliance Sentinel — tracks donor compliance obligations, consent frameworks, and data-sharing constraints.
• Forecasting Agent — scenario-models programme delivery, budget, and beneficiary reach against uncertainty.
• Psychometric Profiling Agent — for mission-led lenders using psychometric credit scoring, generates applicant profiles with full Article 22 compliance.

How context is shared

Specialist agents do not share memory directly. Every agent reads from a shared context store that Freya curates. The context store is tenant-isolated and structured: brand memory, ICP and persona records, campaign history, performance data, approved content, market context, and sector-specific repositories. This design means you can reason about what any given agent sees — it sees the context that Freya explicitly included for that task — and you can reason about who can change that context.

Context is covered in full detail in Persistent Memory — How Freya Learns and Retains, the next document in this section.

Composition into workflows

A workflow is a named, versioned sequence of Freya plans that organisations run on a cadence. Examples: the Monday Morning Brief (weekly), the Monthly M&E Cycle (monthly), the Ministerial Question Response (reactive). Workflows are where agents compose — the Monday Brief, for instance, orchestrates the Analytics, Forecasting, and Copywriter agents in sequence, then surfaces a single artefact for CMO approval.

Workflows are designed and modified in the admin console, version-controlled, and can be scheduled, triggered manually, or triggered on event. See the Approval Workflow Configuration Guide for detail.

One of the most valuable and most often underestimated properties of the platform is Freya's persistent memory. Unlike generic AI assistants that forget everything between conversations, Freya retains institutional knowledge across sessions, across users, and across staff transitions. This document explains what is stored, why it is stored, how it is structured, how it is protected, and how it respects the data-minimisation obligations of the jurisdictions in which Antarious operates.

What is stored

Freya's memory is divided into six durable stores. Each store has a distinct structure, retention rule, and access boundary.

How memory is structured

Each store is backed by a combination of a vector index and a structured record database. The vector index supports semantic retrieval ("find every past brief for campaigns targeting mid-market manufacturing"); the record database supports exact lookups, version history, and access control. Every record has an owner (the user or role that created it), a scope (workspace, team, tenant), and a lineage (what other records informed it).

Memory is tenant-isolated. There is no cross-tenant reading, writing, or inference — not in development, not in production, not for model training. This is enforced at the storage layer, not at the application layer, so it cannot be bypassed by a misconfigured query.

How memory is accessed

Access to memory follows the same role and permission model as access to actions. A user who can read a campaign can read its memory record. A user who can approve ministerial communications can see the memory of past ministerial approvals. An agent only accesses memory that Freya has explicitly included in its context for a given task.

This is important for a reason that does not always get articulated: you can reason about what Freya knows. At any point you can ask Freya to enumerate the memory records that informed a particular decision, and she will do so. This is not a feature tacked on for auditors — it is how the system works internally, so exposing it is essentially free.

Why it matters that memory is persistent

Institutional memory is one of the most fragile assets in any organisation. It walks out with the senior staff member who retires, the programme officer who moves on, the comms lead who takes a sabbatical. In most organisations the loss is invisible until someone asks the question that only that person could answer.

Antarious retains that memory by default. When a user rotates out of a role, the rationale for every decision they made, every campaign they ran, every policy they drafted, every cohort analysis they produced remains accessible to their successor. The successor is not starting cold; they are starting with a retrievable record of what worked, what did not, and why.

This has second-order effects. Reviewing year-over-year patterns becomes cheap; reconstructing the justification for a decision made 18 months ago becomes trivial; onboarding a new team member becomes a matter of granting memory access rather than running a three-month shadow programme.

Privacy and data minimisation

Memory is, by construction, a tension with data minimisation: the more you store, the more you need to protect. Antarious resolves this tension with three design commitments.

01 · Purpose-bound storage. Each memory store has a declared purpose. Brand memory exists to maintain voice consistency. Beneficiary analytics memory exists to improve programme delivery. Records outside a declared purpose are not created, and records whose purpose lapses are flagged for review and deletion.

02 · Configurable retention. Retention periods are set per store and per tenant. The defaults are conservative — most stores retain indefinitely, but personal data stores default to the shortest period consistent with the operational purpose. You can tighten retention below the defaults; you cannot lengthen it beyond the data protection impact assessment (DPIA) declared for the tenant.

03 · Explicit personal-data handling. Memory involving personal data (a named beneficiary, a named counterpart, a named applicant in a lending context) is tagged at ingestion. Tagged records are subject to access logging, retention rules, and subject-rights handling (erasure, rectification, portability). See the data handling and residency reference for the specifics.

What memory is not

Memory is not a training corpus. Antarious does not use tenant memory to train foundation models. It is not a knowledge base to be browsed. Users interact with memory through Freya's task output, not through a "memory explorer." And it is not a permanent record in the sense that it is never reviewed — each store is reviewed periodically for records that have outlived their purpose, and those records are compressed, archived, or deleted according to policy.

The audit trail is the primary output of the platform. Every other feature — the agents, the memory, the approval workflows — produces an audit record as a side effect of doing its work. This document explains what is recorded, how it is stored, how an operator retrieves it, and how to produce the evidence packages that compliance, donor, or regulatory audiences typically ask for.

What is recorded

The audit trail records every event in the platform that has an accountability meaning. Operationally, this means every event that changes state that is visible to another user or to a system outside Antarious. It includes:

• Every action taken by Freya or a specialist agent — action ID, agent ID, inputs, outputs, confidence score, duration.
• Every approval event — action ID, approver identity, decision (approve, reject, request revision), timestamp, rationale if provided.
• Every configuration change — approval graph changes, role changes, permission changes, retention changes, integration credential rotations.
• Every access event involving personal data — who read what, when, for what declared purpose.
• Every alert and escalation — what triggered, who received it, what they did about it, what the outcome was.
• Every data ingestion and egress event — connectors, volumes, timestamps, payload signatures.

Each record is cryptographically chained to the previous record for the tenant. Tampering with a record breaks the chain and is detectable.

How records are structured

Each audit record is a structured, typed document. A typical action record contains: event_id, tenant_id, workspace_id, actor_type (human, agent, system), actor_id, action_type, resource_id, inputs_hash, outputs_hash, approval_chain, occurred_at, confidence, and agent_lineage (which sub-agents contributed).

// Example audit record (shape is illustrative)
{
  "event_id": "evt_01HRT3F...",
  "tenant_id": "tnt_7234",
  "actor_type": "agent",
  "actor_id": "agent.copywriter",
  "action_type": "draft.email_sequence",
  "approval_chain": [
    { "role": "content_strategist", "user_id": "usr_112", "decision": "approve", "at": "2026-04-24T09:42:03Z" }
  ],
  "confidence": 0.94,
  "agent_lineage": ["strategist", "copywriter", "brand_guardian"],
  "outputs_hash": "sha256:4e1c..."
}

Records are append-only. An entry cannot be edited or deleted; corrections are written as new records that reference the one they correct. This is how the trail maintains its forensic value.

How records are stored

Audit records are stored in a dedicated immutable log in the tenant's data residency region. They are retained indefinitely by default, though organisations can configure shorter retention where regulation permits or require it. They are hashed into a Merkle chain so that long-range tampering requires rewriting every subsequent record — in practice, it is detectable with a single verification pass.

For archival and regulatory evidence, records can be exported to an external immutable store (object storage with WORM lock, for example). The export itself is an audit event, and the integrity of the export is verifiable by re-hashing.

How to retrieve records

There are four retrieval paths, graded by use case.

• The Audit Console — an interactive view in the admin surface where authorised users can query, filter, and inspect records. Suited to investigation ("show me all approvals by user X on date Y").
• Reports — pre-built templates for common regulatory and donor needs: quarterly compliance report, DPIA evidence pack, donor accountability report, board audit report. Generated on demand with a single action.
• Export — bulk export to a customer-owned location (S3, Azure Blob, SFTP). Useful for long-term archival and for integrating into a SIEM.
• API — programmatic access to the audit log for teams that maintain their own audit tooling. See the API Reference.

Generating an audit report

The most common operational need is to produce an evidence pack for an external audience — an auditor, a donor, a regulator, a customer running procurement due diligence. Antarious ships with templates for the common cases.

To generate a report, open the Audit Console, select the template appropriate to the audience, define the scope (time window, workspaces, action types, roles), and click Generate. The output is a sealed PDF plus the underlying CSV of records. Both artefacts are themselves audit events, so a future auditor can verify that the report you handed over was the one the system produced at that time.

Who can see what

Visibility of audit records is itself role-based. A workspace administrator sees records scoped to their workspace. A tenant-level audit role sees every record across every workspace. An auditor granted a time-bound read-only role sees records within their declared scope for the duration of their engagement. Every view of an audit record is itself an audit event — the log includes who looked at what.

What the audit trail does not do

The trail does not redact its own records. If a record contains personal data, and that data is subject to an erasure request, the erasure is performed on the underlying resource and a reference-only record is preserved in the trail — the trail retains that an action occurred, even when it cannot retain the content of the action. This is a deliberate design decision: the alternative would allow an erasure request to be used to hide an action entirely, which is not consistent with the regulatory meaning of the right to erasure.

The trail also does not store outputs larger than a configurable threshold. For large artefacts (a full donor report, a board deck, a spatial dataset), the trail stores a cryptographic hash and a pointer to the artefact in the document store. The pointer is privileged; the hash is not. This means the trail remains small and fast while still being forensically sound.

Where this goes from here

This document is the operational overview. For the implementation details (schema, storage, retention, export format, and verification protocol) see Audit Trail Reference in Section 06.

A well-planned Antarious deployment typically reaches productive use between weeks three and six, and reaches full scope between weeks eight and sixteen. The variance is driven less by the platform than by the organisation's own readiness — how clearly data sources are inventoried, how quickly governance decisions are made, and how much patience the team has for the initial approval-cadence tuning. This guide walks through the planning work that most strongly determines those factors.

Phase 0 — Inventory and intent

Before touching the admin console, produce three artefacts. A data-source inventory listing every system Freya will read from or write to, with a designated owner for each. A purpose register stating the intended use of the platform for each workspace — "donor reporting for the FCDO education portfolio" is a good purpose; "AI stuff" is not. A stakeholder map identifying the named human approvers for each severity level. These three artefacts answer the questions the configuration will shortly ask.

Phase 1 — Foundation (weeks 1–2)

Create the tenant in the chosen residency region. Configure SSO against your identity provider. Define the first workspace and assign the initial administrative role. Connect the two or three highest-value data sources — the ones without which the rest of the deployment has no purpose. Configure retention on each memory store. Commission the audit console for your compliance lead and confirm they can query successfully.

Phase 2 — First Useful Output (weeks 2–4)

Enable three to five agents — not the whole library. The aim is to produce one end-to-end artefact that a named approver signs off, so the team feels the full approve-before-execute rhythm. Choose agents whose outputs are low-stakes enough that the initial tuning does not create anxiety: typically a Copywriter, an Analytics agent, and a Document Generator or Report Generator for the sector. Run them on a narrow slice of real data, not a synthetic dataset.

Phase 3 — Approval Graph Tuning (weeks 3–6)

Refine the routing defaults to your organisation's actual review chain. Most deployments discover here that their existing approval conventions are less consistent than they thought — two donors require different approval depths, one government department routes to a legal reviewer that another does not. Tuning is iterative; expect two to three revisions before the graph feels natural.

Phase 4 — Widening Scope (weeks 4–10)

Enable additional agents. Add more data sources. Introduce workspace-per-programme or workspace-per-client patterns if your operating model benefits from them. Move routine actions from "always review" to "review exceptions only" as confidence builds. Configure scheduled workflows (Monday Brief, monthly M&E cycle, quarterly compliance review).

Phase 5 — Go-live and beyond (weeks 8–16)

Full scope of agents and integrations active. The platform is running as part of the daily operating rhythm. Governance cadence includes a monthly approval-graph review, a quarterly compliance evidence generation, and a half-yearly deployment-health review against the success metrics the project sponsor defined in Phase 0.

Deployment checklist

• Tenant created in correct residency region, SSO tested, MFA enforced on admin roles
• At least one workspace with a declared purpose and a named lead
• Approval graph defined for each severity level; senior-role escalation covered
• Data-source inventory complete; credentials rotated post-deployment
• Audit console accessible by compliance; first report generated end-to-end
• DPIA reviewed where personal data is in scope; retention set per store
• Training delivered to named approvers; operational runbook signed off
• Success metrics defined, baselined, and scheduled for review

Deployments fail — or more commonly, under-deliver — for reasons that are usually detectable in advance. This assessment surfaces those reasons while a deployment is still cheap to adjust. Run it before signing a contract, not after.

Readiness dimension 01 · Data infrastructure

Can you name a source of truth for your core data? If three systems disagree about the number of active customers, programmes, or beneficiaries, Freya will inherit that ambiguity. The platform does not resolve authority disputes — it surfaces them and escalates. Before deployment, nominate a source of truth for each major data domain and commit to it.

Evaluate credential hygiene on your integration targets. Shared service accounts, unrotated keys, and admin-level accounts used for daily work are all common — but they make the audit trail less meaningful. A clean deployment pairs with a credential-rotation exercise.

Readiness dimension 02 · Governance

Approval graphs require named approvers. Organisations that run on implicit delegation ("Sam usually signs off on this") struggle here. Before deployment, establish named roles for at least three severity levels and at least one backup per role.

Where regulated data is in scope, you will need a DPIA (if under UK or EU GDPR) or equivalent impact assessment. The platform team can provide templates. Allow four weeks for this to complete if it is not already in place.

Readiness dimension 03 · Team

You need an executive sponsor who will make the "how tight is the approval graph?" call when the team cannot agree. You need an operational lead who will own the day-to-day running of the deployment. You need a technical contact for the connector configuration. These three roles must be staffed before kick-off; implementation partners can augment them, not replace them.

Readiness dimension 04 · Change capacity

Antarious changes how approvers spend their time. Instead of reading drafts slowly, they review AI-assisted drafts quickly and at higher volume. This is a shift some individuals find easier than others. The deployment is more durable when approvers are included in the decision to adopt rather than surprised by it.

Self-scoring

Score each dimension 1 (not ready) to 5 (ready). A combined score above 14 typically predicts a smooth deployment. Below 10, the deployment is likely to underperform unless foundational work is completed first. Between 10 and 14, the deployment will work, but expect some friction in the first two phases — and build the friction into your timeline rather than pretending it will not happen.

This document lists the prerequisites for the most commonly integrated source systems. Each section names the credentials required, the required permission scopes, expected rate limits, and the field-mapping decisions that you should make before the connector is configured.

CRM platforms (Salesforce, HubSpot, Salesforce NPSP)

Create a dedicated integration user with a least-privilege profile that includes Read and Modify on the objects in scope (typically Account, Contact, Opportunity, plus custom objects for NPSP). Grant API-only access so the user has no UI privileges. Enable refresh-token OAuth and record the token rotation policy. Decide in advance which CRM fields are authoritative and which are derived — Freya will write back to derived fields, not authoritative ones.

Field data platforms (ODK, KoBoToolbox, SurveyCTO, CommCare, DHIS2)

Issue a service account with project-scoped read on the forms in scope. For KoBo, generate a project token rather than using your personal token. For DHIS2, scope the service account to the specific data elements and organisation units needed; the default "all organisation units" scope is almost never appropriate. Confirm the form schema is stable — schema changes can force re-ingestion of prior submissions.

Government information systems (SharePoint, Microsoft 365, SAP, Oracle ERP, ServiceNow, Power BI, SQL)

These integrations typically require a named enterprise application registration and administrative consent. Define the specific sites, libraries, or tables in scope — avoid tenant-wide grants. For SAP and Oracle ERP, configure read-only service users and negotiate the connection through your existing middleware (BTP, OIC) where standards require it. For SQL databases, connect via a read replica where possible and scope the service user to the specific schemas and tables in scope.

Marketing and outreach (Meta, Google, LinkedIn, Klaviyo, Instantly, Apollo, ZoomInfo, SEMrush)

Most of these platforms require App/Business Manager-level access to generate credentials with campaign-level scope. LinkedIn requires a developer app with specific product grants. Meta requires business verification and specific scope grants per platform (pages, ads, analytics). Expect a 48-hour window for scope requests on LinkedIn; plan around it.

Analytics and data warehouse (Snowflake, GA4, Tableau, Power BI)

For Snowflake, create a role scoped to the specific databases and schemas Freya will read. For GA4, grant the integration service account the Viewer or Analyst role on the property in scope. For Tableau and Power BI, choose embedded-query credentials or export-driven integrations based on where the authoritative data lives — Freya reads both, but writes should be rare.

Generic REST and webhook targets

For custom integrations, use the Antarious REST connector with an API-key or OAuth client-credential scheme. Declare the specific endpoints in scope; the connector will not call endpoints outside the declared allowlist. For webhook receivers, verify the HMAC signatures on every incoming call — do not treat webhook bodies as trustworthy.

Rate-limit posture

Each connector has a rate-limit budget that respects the upstream system's documented limits. For high-volume integrations (a large Salesforce org, a busy Meta ads account), the rate-limit budget is tunable in the admin console. Do not set the budget higher than the upstream system tolerates; over-aggressive polling is detectable and leads to throttling.

An Antarious integration is a scoped, credentialed, audited connection to an external system. The pattern is the same across every shipped connector: authenticate, declare the scope, map the fields, test in a sandbox, promote to production with live traffic, monitor.

Authentication patterns

Three authentication patterns cover the vast majority of integrations. OAuth 2.0 (authorization code) — the integration runs as a named user and inherits that user's permissions. Client-credentials / service account — the integration runs as an application with a declared service role. API key — the integration runs against a pre-shared secret. Prefer OAuth where the upstream supports it; prefer service account where a long-lived integration needs stable permissions independent of a user account; use API keys only where the first two are unavailable.

Field mapping

Field mapping declares which upstream fields correspond to which platform concepts. The mapping is declarative and versioned — a change in mapping is an audit event and is not applied retrospectively to historical data. Reserve the first week of a connector's life for mapping iteration; expect to refine the map as edge cases surface.

Sync cadence

Connectors support scheduled pull, webhook push, or both. Prefer webhooks where the upstream supports them — they are cheaper, lower-latency, and produce less upstream load. Scheduled pulls are essential where the upstream emits no events; tune the cadence to the operational need, not to the theoretical maximum.

Testing

Every new connector is created in sandbox mode by default. Run a minimum of three end-to-end task invocations in sandbox before promoting to production. Confirm that field values reconcile, that write-backs do not corrupt source data, and that rate limits are respected. Promote to production only after sandbox has survived a weekend without intervention.

Monitoring

Once live, a connector is monitored for authentication failures, rate-limit pressure, schema drift (unexpected fields or missing fields), and payload anomalies. Alerts surface in the admin console and in any SIEM that subscribes to the platform telemetry feed.

CRM integrations are the most commonly deployed of the shipped connectors. This guide walks through Salesforce (including NPSP for non-profit deployments) and HubSpot end-to-end. The pattern is similar in both cases: create a named integration application, grant object-scoped access, map fields, promote.

Salesforce (including NPSP)

Create a Connected App in Salesforce Setup with OAuth scopes for api, refresh_token, and offline_access. Restrict the app to Named Users and assign the integration user the least-privilege profile described in the prerequisites document. Generate the Consumer Key and Consumer Secret. In Antarious admin, paste both into the Salesforce connector and complete the authorisation flow.

Define the object scope. Accounts, Contacts, Opportunities are the usual base; for NPSP add Contact-Account relationships, Soft Credit, Recurring Donation, and the relevant custom objects. Exclude objects Freya will not need — a narrower scope is safer and reduces audit noise.

Field mapping is the decision-heavy step. Distinguish authoritative fields (do not write back), derived fields (Freya writes to these with approval), and narrative fields (freely writeable by Freya with approval). Record the choice; it will be re-examined in every quarterly review.

HubSpot

Create a Private App in HubSpot with scopes for CRM Objects, Engagements, Conversations, and Files as needed. Copy the access token to the Antarious connector. Configure object scope similarly to Salesforce; HubSpot's lifecycle-stage field is a common authoritative-vs-derived boundary decision.

Write-back patterns

The three common write-back patterns are: log-only (Freya creates activity records, never updates object fields); field update (Freya updates a narrow set of derived fields with approval); full update (Freya writes to authoritative fields). Most deployments start at log-only for the first month, move to field update in month two, and rarely move to full update without a specific business case.

Testing

Create three test records in the CRM. Run a plan that reads each and proposes a write-back. Confirm the approval surfaces correctly, the write lands in the correct field, and the audit trail records the upstream record ID. Repeat with a rejected approval and confirm the write does not occur.

Field data platforms are distinctive because their schemas evolve with the programmes that use them. A form that collects beneficiary attendance in April does not collect the same fields in October. The connector is built to tolerate schema change without losing historical data.

ODK Collect and KoBoToolbox

Generate a project-scoped token on the ODK Central or KoBo server. Paste the server URL and token into the Antarious connector. Select the forms in scope; each form is treated as a distinct ingestion stream. Submissions arrive via webhook if the server supports it, or via scheduled poll otherwise.

Form schema is fetched on each sync; a schema change produces a schema revision event in the audit trail. Historical submissions remain under the schema they were submitted against; Freya reasons about them with awareness of the schema history.

SurveyCTO

Create a SurveyCTO API user and grant access to the forms in scope. The connector supports both the REST API and the XForm endpoint; prefer REST where available for richer metadata.

CommCare

CommCare integrations are case-centred. Configure the connector against the relevant project space with a scoped API key; select the case types in scope. Freya reads cases, case updates, and associated forms, and can propose case updates through the approval gate.

DHIS2

DHIS2 deployments are heterogeneous — data elements, category combos, and organisation-unit hierarchies vary widely between instances. Configure the connector against a specific DHIS2 user with the minimum organisation-unit scope required. Import data elements by ID rather than by name to avoid collisions in multilingual deployments.

PII and consent

Field data frequently contains personal data about beneficiaries. Every connector in this category is configured with mandatory PII tagging and a declared consent framework. An agent cannot read a beneficiary record for a purpose that is not covered by the recorded consent, even within the tenant boundary.

Government information systems are typically large, heterogeneous, and governed by their own security baselines. Integrations with these systems are more conservative by default than commercial connectors — narrower scopes, stricter network paths, and more explicit change control.

SharePoint and Microsoft 365

Register an enterprise application in Microsoft Entra ID (formerly Azure AD) with the application permissions required: Sites.Selected for SharePoint, Mail.Read where email content is in scope, and explicit grants per site. Administrative consent is required; do not use tenant-wide Sites.ReadAll except under explicit governance authority. Assign the app to the specific sites in scope with site-level role grants.

SAP

SAP integrations route through SAP Business Technology Platform (BTP) or through an existing SAP-ERP middleware layer. The connector authenticates through the middleware with service credentials scoped to the specific modules and transactions in scope. Read-only roles are the default; write-back is discouraged in public-sector deployments without explicit change-management approval.

Oracle ERP

For Oracle ERP Cloud, use the REST APIs with a named integration user. For on-premises E-Business Suite, route through Oracle Integration Cloud or an equivalent middleware. In both cases, scope access to the specific business objects in use, and prefer read replicas where possible.

ServiceNow

Configure a ServiceNow integration user with table-scoped read and create/update permissions where write-back is needed. Prefer the Scripted REST API for bespoke queries over the generic Table API, as it keeps the integration narrower and easier to audit.

Power BI

Two patterns: read the underlying data sources directly (preferred) or read via the Power BI REST API (where source access is not available). If reading via Power BI, scope to specific workspaces and report datasets; avoid the admin-only APIs unless no narrower alternative exists.

SQL databases

Connect to a read replica rather than the primary where the architecture supports it. Use a database role scoped to specific schemas. Prefer TLS-bound connections to private networking paths, and record the connection identity in the integration metadata so a DBA can correlate platform reads with database telemetry.

Network topology

Public-sector deployments typically require private connectivity rather than public internet egress. The platform supports Azure ExpressRoute, AWS Direct Connect, and equivalents on request for qualifying customers. Configure the integration to egress through the private path and block the public fallback.

Marketing platforms are fast-moving — ad creative, budget allocation, audience targeting, campaign status change in near real time. The connectors here support both read and write paths, and write-back is a more common pattern than in the governance-heavy integrations.

Meta (Facebook, Instagram)

Complete Meta Business Verification for the org. Create a System User in Business Manager with Admin or Employee role as appropriate; generate an access token scoped to the pages, ad accounts, and pixels in use. Paste into the Antarious Meta connector. For ad management, the Meta Ads Agent will propose campaign changes; all changes pass through the approval gate before execution.

Google Ads and GA4

For Google Ads, create a Manager account (MCC) or grant the integration service account admin access to the specific ad account. Generate a developer token. For GA4, grant the service account Viewer or Analyst role on the property.

LinkedIn

Register a LinkedIn Developer App with the specific product grants needed (Marketing Developer Platform for ads, Sales Navigator for prospect signals, and so on). Several grants require LinkedIn approval; plan for a 48-hour review window. Limit the grants to those in active use — reducing grants later is straightforward but requires a small amount of downtime.

Klaviyo, Instantly

Both platforms support API-key authentication. In Klaviyo, create a Private API Key with full access to Profiles, Lists, Events, and Campaigns. In Instantly, generate a workspace-scoped API key. For both, configure the campaign-level webhook subscriptions so Freya sees delivery, open, and reply events in near real time.

Apollo, ZoomInfo, SEMrush

All three use API-key authentication against their respective data platforms. Respect each platform's rate budget; high-volume prospect lookups (10k+ records per day) frequently trigger throttling or contract-limit warnings. The platform will surface these at the connector level.

Attribution configuration

Once the connectors are live, configure the attribution model the Analytics Agent will run. Five models are supported: first-touch, last-touch, linear, time-decay, and position-based (40-20-40). The default is position-based; attribution windows are 30 days post-click and 1 day post-view for paid, and 90 days for organic touchpoints. These defaults can be tuned per tenant.

Analytics and warehouse integrations are mostly read-focused. Freya queries the warehouse for evidence that supports the artefacts she produces; she rarely writes back to it. The integration pattern therefore prioritises safe, performant reads and avoids the write-back considerations that dominate CRM integrations.

Snowflake

Create a role scoped to the specific databases and schemas in use; grant USAGE on the warehouse plus SELECT on the objects in scope. Use a named service account with password-plus-key-pair authentication. Configure a query tag so platform queries are identifiable in Snowflake's query history.

GA4

Grant the integration service account Viewer or Analyst role on the property. The connector uses the GA4 Data API for analysis queries and the Admin API for property metadata. Configure the cadence — typically daily is enough for analysis queries; hourly for anomaly detection.

Tableau and Power BI

Both platforms support embedded-query authentication through their respective REST APIs. Prefer to connect Freya directly to the data source underneath the dashboard rather than to the dashboard itself — this allows Freya to re-query in a different shape rather than being constrained to the dashboard's filter panel. Where the dashboard contains derivations not present in the source, the dashboard-layer integration remains available.

Data model mapping

Map warehouse tables to platform concepts. A fact table of campaign performance maps to the Analytics Agent's performance view; a dimension table of customers maps to the ICP Researcher's profile view. The mapping is versioned; a change is an audit event.

Custom integrations extend Antarious to sources not covered by shipped connectors. The REST API is the supported surface; this guide walks through the design pattern for a typical custom integration end-to-end.

Pattern

A well-formed custom integration consists of four parts: an ingestion path (the external system pushes data into Antarious, or Antarious pulls from it), a schema declaration (the shape of the data being exchanged), a webhook subscription (so the external system can react to approval and execution events), and a governance binding (scoped API keys, declared purpose, audit coverage).

Authentication

Create an API key in the admin console scoped to the specific endpoints the integration uses and with the narrowest permission bundle that works. Record the expected rotation cadence at issuance — rotate at least annually; more frequently for high-volume integrations.

Ingesting data

To push data into Antarious, POST /v1/workspaces/:workspace_id/memories with a record that declares its type, its PII tag, and its purpose. Records are validated at ingestion; invalid records return a structured error and do not land in the memory layer. For high-volume ingestion, use batched endpoints (POST /v1/memories:batch) with up to 500 records per call.

Subscribing to webhooks

Subscribe to the events your integration needs: task.completed, approval.requested, approval.decided, artefact.created, audit_event.created. Each delivery is HMAC-signed; verify the signature on every call. Failed deliveries are retried with exponential backoff for 24 hours.

Receiving approved outputs

When Freya produces an artefact intended for a custom destination, the delivery is a webhook-driven event; the payload references the artefact in the platform's document store, and the subscriber fetches the content via an authenticated read. This keeps artefacts inside the tenant boundary and ensures the fetch itself is audited.

Error handling and idempotency

All writes support an Idempotency-Key header; use a UUID per logical operation. Errors return the platform's consistent error envelope with a request_id that correlates to platform-side logs and audit events.

Testing and promotion

Start in a sandbox workspace with synthetic data. Move to a production workspace with a narrow scope (one real data source, one small cohort of approvers) and widen once stability is established. Every ingestion endpoint tags records with the source integration ID, so an integration that misbehaves can be quickly bounded.

Roles in Antarious are the mechanism that ties together permissions, scope, and approval authority. A well-designed role set is the difference between a deployment that operates smoothly and a deployment whose approval queue becomes a bottleneck. This guide walks through the role model, the permission dimensions, and three worked examples drawn from real deployments.

The four permission dimensions

Every role is defined along four independent dimensions:

• Resource — which workspaces, agents, memory stores, connectors the role can address.
• Action — read, write, approve, configure.
• Scope — tenant-wide, workspace-specific, team-specific.
• Purpose — the declared reasons for which the role can exercise its permissions.

A permission is the intersection of the four. A role can read programme data (resource: memory, action: read) in the East Africa workspace (scope) for reporting purposes (purpose). The same role cannot read the same data for an operational purpose unless that purpose is also granted.

Built-in role archetypes

The platform ships with a set of archetypes that cover common patterns: Administrator, Workspace Lead, Operator, Approver, Auditor, Viewer, Integration Service Account. Start from an archetype and narrow it. Creating roles from scratch is supported but rarely necessary.

Worked example — GTM agency

An agency running Antarious on behalf of clients typically uses: Agency Admin (tenant-wide admin, not granted to client personnel), Client Lead (workspace-scoped admin for a single client), Content Strategist (approve on content artefacts in the workspace), Media Buyer (approve on paid-media actions up to a budget threshold), Viewer (read-only for client-side stakeholders reviewing the work).

Worked example — government department

A ministry typically uses: Permanent Secretary (approve critical-severity actions), Director (approve high-severity actions), Policy Lead (approve medium-severity policy outputs), Operations Lead (approve medium-severity operational outputs), Legal Reviewer (mandatory parallel approver on public-facing outputs), Auditor (read-only audit access scoped to a department with a time-bound grant during an engagement).

Worked example — NGO / development organisation

A programme office typically uses: Country Director (approve programme-level actions), Programme Manager (approve programme-specific operational actions), M&E Officer (approve donor report drafts), Field Team Lead (submit and approve field data), Compliance Officer (parallel approver on donor-facing outputs), Donor Liaison (view-only with access to donor-scoped artefacts only).

Principle of least privilege

The tempting shortcut is to grant broad permissions early and narrow them later. In practice, narrowing is harder than widening — users get used to seeing what they see. Grant the minimum, widen in response to an articulated need, and review quarterly.

Approval workflows are the configurable expression of your organisation's governance on top of the platform's invariant Human-in-the-Loop architecture. A workflow declares, for a class of action, who must approve, in what order, and under what conditions.

Workflow primitives

Workflows compose from a small set of primitives: Approver (a role or named user), Gate (a decision point that halts execution), Branch (conditional routing on an attribute), Parallel (multiple approvers in any order), Sequence (approvers in declared order), Escalation (a timer that routes to a fallback approver if the primary does not respond).

Common templates

• Single review — one approver. Suited to low-severity standard content.
• Two-step review — content review then line-manager sign-off. Suited to standard external output.
• Parallel legal + policy — both approvers must clear in any order. Suited to public-facing communications.
• Threshold budget — routes on budget value; under £X to Media Buyer, over £X to Director, over £Y to CFO.
• Sequential donor — M&E Officer drafts, Programme Manager reviews, Country Director approves.

Escalation patterns

Every workflow should specify what happens if the primary approver is unavailable. Defaults: 24-hour SLA before escalation, fallback to a named delegate, second-tier fallback to the role's line manager. Workflows with an uncovered fallback path are flagged during design review.

Version control

Workflows are versioned. A change to a workflow is an audit event; the workflow in force at the moment of each approval is preserved so an auditor can reconstruct the governance state that authorised a past action.

Simulation

Before promoting a new workflow, simulate it with a test action. The simulator walks through the routing and surfaces who would be asked, in what order, and what the fallback path is. Most misconfigurations surface in simulation rather than in production.

Delegation is the most abused feature in most approval systems. It is also indispensable — a director on leave cannot hold up every approval for a week. Antarious supports delegation with a set of governance controls that preserve accountability even when the named approver is not the acting approver.

Delegation forms

Three forms are supported:

• Scheduled delegation — declared in advance for a specific window. Often used for planned absence.
• Standing delegation — a permanent delegate for a specific action class. Used where the primary approver has a subject deputy.
• Ad-hoc delegation — an approver delegates a specific pending action to a specific person. Carries a mandatory rationale.

Boundaries

Delegation cannot exceed the delegator's own authority — a director cannot delegate critical-severity approvals if the director does not themselves hold that authority. Delegation cannot be recursive more than one step: a delegate cannot re-delegate. Delegation of mandatory legal or compliance approvals is restricted to specific named deputies.

Time-bound access

External auditors and time-limited consultants receive time-bound access grants. A grant declares a role, a scope, a purpose, and an end-time. At the end-time the grant expires automatically; the grantor can extend with a new audit event. Every grant is surfaced on the governance dashboard so an administrator can see all currently active external access at a glance.

SSO is strongly recommended and, for tenants on the Scale and Agency plans, enforced by default. This guide walks through configuration for the three most common identity providers and for generic SAML 2.0 providers.

Microsoft Entra ID (formerly Azure AD)

Register Antarious as an Enterprise Application. Configure SAML-based sign-on with the ACS URL and entity ID provided in the Antarious admin console. Map the necessary claims: emailaddress, name, groups (if group-based role assignment is used). Grant user or group access to the application; by default, no one can log in to Antarious even after the app exists.

For SCIM-based provisioning, configure the Antarious SCIM endpoint with the provided bearer token. Provisioning creates and deactivates accounts in sync with your directory; deactivated users lose access immediately, and their pending approvals route to the delegated fallback.

Google Workspace

Create a SAML application in the Admin console. Import the Antarious metadata XML. Map primary email and name; group memberships can be mapped via custom attributes. Grant organisational-unit-level access to the app. SCIM is not supported for Google Workspace at time of writing; accounts are provisioned just-in-time on first login.

Okta

Create a SAML 2.0 app from the Antarious integration in the Okta catalogue (or create a generic SAML app and paste the Antarious metadata). Assign users or groups. For SCIM, use Okta's Lifecycle Management add-on with the Antarious SCIM endpoint.

Generic SAML 2.0

Any SAML 2.0-compliant IdP works. Import the Antarious SP metadata, configure ACS and entity ID, map the required claims, and grant access. If your IdP supports SCIM 2.0, provisioning is available through the same endpoint as the named providers above.

MFA and conditional access

MFA is enforced at the IdP level rather than at the Antarious level; this is deliberate, so that MFA policy remains under the customer's existing controls. If your IdP supports conditional access (device compliance, location, risk), those policies are the recommended way to strengthen access to the platform.

This guide covers the 13 business agents: how to enable them, how to tune them to your organisation's voice and policies, and how to compose them into the workflows that drive the GTM operating rhythm.

Enabling agents

Open the workspace's Agent Library in the admin console. Each agent has an enable toggle, a description of what it does, the data sources it reads from, and the actions it produces. Enable only the agents you intend to use — disabled agents are invisible to Freya's planning loop and cost nothing.

Per-agent configuration

GTM Strategist — define the markets, channels, and budget ceilings in scope. Attach the ICP record the strategist should optimise against.

ICP Researcher — connect to the CRM win/loss data. Declare whether to include open opportunities as signal or restrict to closed-won.

Competitor Intel — add the competitors to track. The connector-level budget determines how often the competitor sites, ad libraries, and review platforms are polled.

Copywriter — attach the brand guideline memory store. Define the banned-phrase list and the voice descriptors (formal/conversational, confident/measured).

Meta Ads — select the ad accounts in scope. Declare the budget autonomy threshold: under $X the agent can reallocate within a campaign without approval; over $X it requires Media Buyer sign-off.

SEO — connect Search Console and the content management system. Declare the publishing surface (blog, resources, landing pages) and the approval gate for new pages.

Social Media — connect the social accounts in scope. Define the posting cadence and the approval workflow — some teams pre-approve a calendar, others review post-by-post.

Brand Guardian — set the minimum compliance score threshold. Default is 0.75 (below returns, above passes); some brands raise to 0.85 for public-facing output.

SDR Outreach — import or define sequence templates. Declare the reply-classification categories and the escalation paths — hot replies surface to a named SDR; objection replies route to a sales engineer.

Analytics — select the attribution model and the report cadence. Configure the anomaly-detection sensitivity per metric.

Forecasting — declare the forecast horizon (typical: 90 days) and the scenario labels (base, optimistic, risk). Attach the historical performance data the forecast should ground on.

Customer Service AI — define the auto-response categories and the escalation criteria. Set the confidence threshold for auto-reply; below the threshold, route to a human agent.

Voice AI Agent (Beta) — select the phone numbers in use. Declare the allowed inbound and outbound purposes. All calls produce a transcript in the audit trail.

Composing into workflows

The Monday Morning Brief composes Analytics + Forecasting + Copywriter. The Quarterly Business Review composes Analytics + Forecasting + GTM Strategist. The Monthly Content Cycle composes SEO + Copywriter + Brand Guardian + Social Media. Agencies running multi-client deployments typically duplicate these workflows per client workspace.

The government agent library is tuned for ministries, agencies, and public bodies. Each agent carries defaults that are more conservative than their commercial counterparts — more mandatory approvals, more mandatory reviewers, tighter scope on external-facing outputs.

Policy Intelligence Agent

Declare the jurisdictions, subject areas, and source set (Parliament, government press releases, regulatory publications, specific think-tank outlets). Configure the cadence — typically daily. The agent drafts an internal briefing note; approval surfaces the note to the policy lead and, optionally, to the permanent secretary's office.

Service Delivery Monitor

Attach the relevant KPI definitions and the delivery-unit directory. Configure anomaly sensitivity per KPI: strict on targets the department is publicly accountable for, loose on internal operational metrics. Alerts surface to the Operations Lead with the underlying time-series chart.

Budget Tracker

Connect to the departmental finance system (typically SAP, Oracle ERP, or a ministry-specific platform). Declare allocation categories and the end-of-year forecast model. Variance alerts surface to the finance lead with drill-down to line-level commitments.

Compliance Sentinel

Load the department's obligation register — statutory duties, regulatory requirements, policy commitments. The agent continuously checks operational data and document output against the register and surfaces gaps. Evidence portfolios for inspection are generated on demand in the format the regulator expects.

Document Generator

Define the document classes in scope (briefings, Cabinet papers, consultation responses, parliamentary question answers, ministerial correspondence). Each class has a template, a source-data declaration, and a mandatory approval chain. The class defines the default reviewers; specific documents can add reviewers but cannot remove them.

Inter-Departmental Coordinator

Build the cross-departmental dependency map. The agent monitors shared commitments and surfaces coordination risks — a policy commitment that depends on another department's delivery, a joint programme that has drifted out of synchronisation.

Public Communication Agent

This agent operates under the strictest approval chain. Every external output — press release, social post, public guidance — requires editorial, legal, and comms-head approval in parallel. No default setting allows auto-release of public-facing output.

Strategic Forecasting Agent

Configure the horizon (1–5 years), the scenario dimensions (demographics, economic assumptions, policy variants), and the sensitivity dials. Scenario packs are versioned; the version in force at the moment of a decision is preserved for retrospective review.

The NGO / Development agent library is designed for organisations answerable simultaneously to donors, regulators, and beneficiaries. Its defining feature is that every configuration that touches personal data requires explicit consent and purpose declarations; the defaults are the most conservative of the three libraries.

Programme Intelligence Agent

Load each programme's log frame (logical framework) and theory of change. The agent scores incoming data against expected outputs and outcomes, surfacing divergence as it develops. Thresholds are programme-specific; a small deviation in a pilot programme carries different weight than a matching deviation in a scaled programme.

M&E Report Generator

Configure per-donor reporting templates. Map field data sources to log-frame indicators. Declare the approval chain (M&E Officer → Programme Manager → Country Director is typical; donor-specific variants are common). The agent drafts; approvers review against source data links; the final artefact is released to the donor portal through an audited connector.

Partner Performance Monitor

Import the implementing-partner directory. Define the performance dimensions (delivery, compliance, reporting, financial) and the scoring weights. The agent generates a monthly partner scorecard and surfaces partners at risk.

Field Data Analyst

Connect the field-data platforms in use (ODK, KoBo, SurveyCTO, CommCare, DHIS2). Declare the data-quality rules — outlier thresholds, required fields, cross-form consistency checks. The agent cleans and interprets submissions; dirty submissions route to a data steward for reconciliation.

Beneficiary Analytics Agent

Beneficiary data is PII-tagged on ingestion and operates under strict purpose binding. Configure the analytical purposes (equity-gap analysis, dropout risk, outcome prediction) each of which must be consistent with the consent framework in use. Outputs are aggregate by default; beneficiary-level outputs require explicit senior approval.

Loan Portfolio Monitor

For mission-led lenders. Attach the loan-management system. Configure arrears thresholds and early-warning indicators. The agent surfaces at-risk loans with recommended officer actions; actions are approved at the loan-officer level for small balances and at the portfolio-manager level for larger balances.

Document Drafting Agent

Configure the document classes (concept notes, proposals, MoUs, case studies). Each class has a template, a reviewer chain, and a source-data declaration. Case studies, in particular, require explicit consent from named beneficiaries before they can be drafted.

Compliance Sentinel

Load the donor-specific compliance register (FCDO, USAID, BMZ, private foundations). The agent monitors programme activity for compliance gaps — missing consents, late reports, procurement policy exceptions — and surfaces them to the compliance officer.

Forecasting Agent

Configure scenario dimensions relevant to the programme (funding environment, security environment, counterpart capacity). Forecasts are surfaced alongside confidence intervals; decisions made under high uncertainty are flagged as such in the audit trail.

Psychometric Profiling Agent

For mission-led lenders using psychometric credit scoring. Configure the assessment instrument, the decision thresholds, and — critically — the appeal path. The agent produces a recommendation; the human credit officer decides. This agent operates under explicit Article 22 compliance: no credit decision is made by the agent, only recommended.

The failure mode for a new Antarious operator is turning on too much in the first session. Freya feels, on day one, like an intern who will do anything you ask — which is exactly when the temptation is highest to ask too much. This guide sets out a deliberate on-ramp most customers find productive.

Day 1 — watch the Review queue

Log in at antarious.vercel.app. The Review queue is the first surface. It already has sample items — a campaign draft, a weekly report, an A/B test proposal. Read each. Approve, annotate, or reject. Do not dispatch new work yet.

Day 2 — open the Campaign Briefer

Brief a small campaign you would run anyway this week. Keep Manual mode on. Watch Freya reflect the brief back; notice which clarifying questions she asks.

Day 3 — switch to Semi-Auto for one workflow

Pick the workflow with the most predictable output — usually the weekly performance report. Switch it to Semi-Auto. Approve the next artefact that drops.

Day 5 — enable a second agent

Open the Agent Library. Enable one more agent that is genuinely useful to your team (Analyst for most teams, Brand Guardian for regulated teams, Partner Performance Monitor for NGO programmes). Leave the rest off.

The Review queue is the platform's conscience. Everything Freya produces that requires human decision surfaces here. When the queue is clean, the system is operating well; when it backs up, something upstream is misconfigured.

Item types

Campaign drafts, performance reports, ad-copy variants, social posts, outreach sequences, A/B test proposals, anomaly alerts, approval escalations, exception reports from Agentic runs. Each item declares its agent provenance and its severity class.

Triage

Work from the top. The queue orders by severity-weighted freshness: a critical-severity item that appeared ten minutes ago outranks a low-severity item from yesterday. Approvals that will cascade (the report that unblocks a launch, the brief that unblocks three downstream drafts) are flagged with a chevron.

Annotation conventions

Approval is signal, rejection is stronger signal, annotation is strongest signal. When you reject, leave a one-line reason. The reason is captured in Freya memory and weights future drafts away from the same failure class. Teams that annotate consistently see their rejection rate fall over the first six weeks.

Queue hygiene

A queue older than 48 hours is a smell. If items are sitting that long, either approvers are under-staffed for the configured workflow, or Agentic mode should take more weight (fewer items ask for review). Both are real diagnoses; neither is fixed by ignoring the queue.

The Campaign Briefer is where you set intent. It is Freya's equivalent of a creative brief in an agency — and just like an agency brief, the quality of the output is bounded by the quality of what you put in.

The six fields

• Goal — what changes if this works. Concrete, measurable. Not "raise awareness"; rather "350 qualified demo requests in region X by 12 May."
• Audience — who you are trying to reach. Anchor on the ICP record if one exists; describe in prose if not. Say who you are not targeting.
• Channels — where the campaign will run. Freya will enable only the agents relevant to the declared channels.
• Budget — total spend envelope and the autonomy threshold. Under the threshold, Freya reallocates without approval; over, she routes to the budget approver.
• Non-negotiables — banned phrases, legal-review requirements, regional restrictions, brand rules that take precedence over tactical wins.
• Success metric — the single number that determines whether the campaign worked. Secondary metrics are allowed; the primary is what Freya optimises against.

Brief memory

Each approved brief becomes part of Freya's memory of your brand. Across campaigns, the non-negotiables compound; you do not restate them each time. When a new campaign is briefed, Freya surfaces the existing rules and asks if any change applies for this campaign.

A workflow is a named chain of agents plus the approval gates between them. The Workflows library sits under the Workflows entry in the dashboard navigation — in the live demo, it lives at /freya/workflows (the route is stubbed but the library concept is the one that matters here).

Shipped workflows

• Monday Morning Brief — Analyst reads last-week performance, Forecasting projects next-week trajectory, Copywriter drafts the brief.
• Monthly Content Cycle — SEO keyword refresh, Copywriter drafts, Brand Guardian scores, Social Media schedules.
• Quarterly Business Review — Analyst + Forecasting + GTM Strategist compose the pack.
• Donor Report (FCDO / USAID variants) — Field Data Analyst + M&E Report Generator + Compliance Sentinel.
• Cabinet Paper — Policy Intelligence + Document Generator + Inter-Departmental Coordinator with parallel legal review.

Forking

Any shipped workflow can be forked into your workspace. The fork becomes yours to modify; the original continues to receive upstream updates independently.

Authoring your own

A workflow is a YAML-like definition listing agents, their parameters, the data they pass to each other, and the approval gates between steps. Authoring is done in the workflow editor; advanced users can edit the definition directly.

Antarious exposes two memory surfaces. Knowledge is what you give the system — documents, datasets, structured records. Memory is what the system has learned from working with you — approvals, rejections, annotations, outcomes. Operators who use both well see their output quality rise through the first quarter of deployment.

Knowledge

Accessed at the Knowledge entry in the navigation (/knowledge in the demo). Ingest brand guidelines, product documentation, previous campaigns, historical reports, consent registers, statutory obligations. Every ingested document declares its scope (workspace / team / tenant) and its retention policy.

Freya Memory

A first-class surface showing what Freya has learned. Voice preferences, approval patterns, rejection reasons, successful campaign archetypes, anti-patterns to avoid. Memory is editable — an operator with the right role can annotate "this learning was a local spike, not a rule" and Freya will stop generalising from it.

Freya Intelligence

Where Memory meets Knowledge. Intelligence is the surface that surfaces proactive insight — a competitor's repositioning, a policy shift, an emerging anomaly — drawn from the combination of ingested knowledge and learned patterns. Intelligence items enter the Review queue when they cross a salience threshold.

Approval History is the complement to the Review queue. The queue holds items awaiting decision; Approval History holds every decision made. Filter by approver, by date range, by action class, by workflow. Export produces a signed PDF with the workflow definition, the artefact versions, and the approver chain — the package an auditor expects.

The history is immutable. Corrections to a past decision are added as a superseding record with a rationale; the original is preserved.

Every unit of agent work in Antarious consumes credits. The credits model exists for two reasons: it lets you budget agent work the way you budget any other operating expense, and it gives an honest signal about which workflows are carrying their weight.

What consumes credits

• Agent runs — each dispatch of an agent consumes credits proportional to the complexity of the work. Copywriter drafts are light; Forecasting runs are heavier.
• Tool use — connectors that reach out to third-party systems (search, ad platforms, CRMs) consume credits per call, on top of the underlying agent cost.
• Memory reads and writes — at scale, memory operations are non-trivial. At the volumes most customers operate, they are a small share of total spend.

Budgeting

Credit allocations can be set at tenant, workspace, team, or campaign scope. A campaign can declare a credit cap; agents will throttle or halt when the cap is approached. The workspace dashboard shows credit burn alongside campaign performance so the ROI conversation is grounded in real numbers.

The live demo ships three workspaces on the Agency tenant — Medglobal, the Antarious agency workspace, and a Sandbox. They demonstrate the default isolation pattern: every workspace is a separate Knowledge store, a separate Memory, a separate set of connectors, and a separate credits budget. The dashboard switcher at the top-right swaps contexts cleanly.

What is shared across workspaces

Tenant-level policies (data residency, SSO configuration, tenant administrators, retention defaults) apply to every workspace. Shipped workflows and agents are available in every workspace; forks are workspace-local.

What is isolated

Client data, brand voice, campaign history, Freya memory, approval chains. A media buyer on one client's workspace cannot see another client's campaigns by default; cross-workspace roles exist but require explicit tenant-admin grant.

Credits pooling

Tenant-level credits pools can be shared across workspaces or split per workspace. Agencies typically split per client so billing rolls up cleanly; in-house multi-brand operators typically pool for operational flexibility.