What your AI workforce can actually do
across client accounts
25 approved capabilities across advertising, commerce, CRM, files, content,
publishing, research and agency operations — each one honest about what is available today,
what runs as a guided pilot, and what still has to be built.
These are workflow patterns, not 25 separate products. They run on the same
access layer: approved credentials the agent never sees, the right client workspace, human
approval where it matters, and an audited trail.
13Available with guided setup7Limited guided pilot1Custom workflow3Released platform capability1Planned
The Outloop Capability Catalog is the list of business workflows AI agents can run across client accounts through approved access.
Each capability names the systems it touches, the actions it takes, which of those stop for human approval, and what is configured separately in every client workspace. Availability is stated plainly — available with guided setup, limited guided pilot, custom, released platform capability, or planned.
Start here — the most established workflows
Every one of these has a documented access path you can read before committing to anything.
Setup is still guided: the accounts, resources, context and approval rules are configured per
client workspace.
Keep client search accounts clean and governed — wasted spend surfaced weekly, every change reviewed before it lands.
Google AdsGoogle AnalyticsGoogle Search Console
Read Analyze Recommend Approval required
Human control ·
Budget, bid, status and structural changes stop for approval. Account-level deletions are blocked outright.
Per workspace ·
The client's own Google Ads account, the approved scopes, spend guardrails, the named approver, and the success metric the account is judged on.
Worth knowing: Search-term and waste analysis is the strongest part. Automated bid and budget changes stay approval-gated by design — this is not an autonomous bid manager.
What this capability does+
The problem
Every client account drifts. Search terms leak budget, negatives go stale, and nobody has time to audit weekly across a full roster — so the audit happens when a client complains.
What the agent can do
—Classify search terms as keep, negative candidate, needs review, or do not touch
—Surface budget pacing and spend anomalies against the account baseline
Search-term and waste analysis is the strongest part. Automated bid and budget changes stay approval-gated by design — this is not an autonomous bid manager.
What we configure
—Approved Google Ads access, scoped to the one account this workspace may touch
—Spend and change guardrails, plus who approves what
—The recurring audit and the report it produces
What you provide
—Which Google Ads account belongs to this workspace
—Who signs off on account changes
—The metric the account is actually judged on
What a real proof looks like
One client account, one weekly audit cycle, one approved change set applied by a human — with the before and after visible.
Catch creative fatigue and account drift across client ad accounts before performance quietly decays.
MetaGoogle Analytics
Read Analyze Recommend Approval required
Human control ·
Pausing ads, moving budget and any status change stop for a named approver. Nothing is paused automatically.
Per workspace ·
The specific Meta ad account this workspace is pinned to, the approved scopes, the fatigue thresholds, and who approves changes.
Worth knowing: Detection and ranking are the proven part. Meta app review and scope approval are their own process per app — plan for that before assuming account access on day one.
What this capability does+
The problem
Paid social decays gradually. By the time a weekly report shows the drop, two weeks of budget have already gone into tired creative.
What the agent can do
—Track creative performance against each ad’s own baseline rather than a global rule
—Flag fatiguing creative only when two or more independent signals agree
—Surface budget and delivery anomalies across the account
—Assemble a ranked review list with the supporting numbers attached
—Hold pauses, budget moves and status changes for approval
Systems used
MetaGoogle Analytics
Reusable across clients
The fatigue signal logic, the ranking rules and the review format are defined once and applied to every client account.
Configured per workspace
The specific Meta ad account this workspace is pinned to, the approved scopes, the fatigue thresholds, and who approves changes.
Where a human decides
Pausing ads, moving budget and any status change stop for a named approver. Nothing is paused automatically.
Detection and ranking are the proven part. Meta app review and scope approval are their own process per app — plan for that before assuming account access on day one.
What we configure
—Approved Meta access pinned to one ad account per workspace
—Fatigue thresholds and the signals that must agree before flagging
—The review cadence and the approval boundary
What you provide
—Which Meta ad account belongs to this workspace
—Who approves pausing or reallocating budget
—Any creative the agency must not touch
What a real proof looks like
One client ad account scanned on a real cycle, one ranked fatigue list reviewed with the team, and one approved action taken by a human.
Find and fix the product feed problems that quietly suppress shopping performance, before the client notices the drop.
Google Merchant CenterGoogle Ads
Read Analyze Recommend Draft Approval required
Human control ·
Feed corrections are drafted and reviewed. Writes back to the feed require explicit approval; bulk destructive operations are blocked.
Per workspace ·
The client's own Merchant Center account, the linked Google Ads account, the product categories in scope, and who approves feed changes.
Worth knowing: Diagnosis and drafting are the strong part. Merchant Center account structures vary enormously between clients, so the connector setup is validated per account rather than assumed.
What this capability does+
The problem
A feed silently drops half the catalogue over a weekend. The error list runs to thousands of rows, so nobody reads it until shopping revenue falls off a cliff.
What the agent can do
—Read product feed status and pull the current disapproval and warning set
—Group issues by root cause instead of listing thousands of item-level errors
—Rank problems by the revenue actually at risk
—Draft the specific feed corrections needed, item by item
—Hold every feed write for approval
Systems used
Google Merchant CenterGoogle Ads
Reusable across clients
The issue-grouping logic, the root-cause taxonomy and the correction templates are reused across every commerce client.
Configured per workspace
The client's own Merchant Center account, the linked Google Ads account, the product categories in scope, and who approves feed changes.
Where a human decides
Feed corrections are drafted and reviewed. Writes back to the feed require explicit approval; bulk destructive operations are blocked.
Diagnosis and drafting are the strong part. Merchant Center account structures vary enormously between clients, so the connector setup is validated per account rather than assumed.
What we configure
—Approved Merchant Center access scoped to this workspace
—The root-cause grouping and the ranking rule
—The approval boundary for any feed write
What you provide
—Which Merchant Center account belongs to this workspace
—Who owns the product feed and signs off on corrections
—Which product categories matter most commercially
What a real proof looks like
One real feed audited, issues grouped by root cause, and one approved correction applied by a human with the disapproval count moving.
Merges and field corrections require approval. Record deletion is blocked outright — the agent proposes, a person disposes.
Per workspace ·
The client's own CRM, which fields are mandatory for their reporting, their staleness definition, and who approves merges.
Worth knowing: High-confidence duplicates are reliable; ambiguous ones are deliberately left for a human rather than guessed. Deletion is never available, by design.
What this capability does+
The problem
Every report starts with an argument about the numbers. Three versions of the same account, half the deals missing a source field, and nobody willing to run a bulk merge.
What the agent can do
—Detect duplicate and near-duplicate records with the matching evidence attached
—Find records missing the fields the client’s reporting actually depends on
—Flag stale records against the client’s own definition of stale
—Propose a merge and correction batch, ranked by confidence
—Apply approved corrections; never delete
Systems used
Zoho CRMHubSpotAirtable
Reusable across clients
The duplicate-matching logic, the confidence model and the batch review format are built once and reused everywhere.
Configured per workspace
The client's own CRM, which fields are mandatory for their reporting, their staleness definition, and who approves merges.
Where a human decides
Merges and field corrections require approval. Record deletion is blocked outright — the agent proposes, a person disposes.
Know which campaigns produce real conversations instead of counting form fills and call volume.
Custom APIAirtableGoogle Ads
Read Analyze Recommend Update Approval required
Human control ·
Writes back to the tracking or CRM record require approval. The agent never contacts a lead.
Per workspace ·
The client's own call-tracking or lead platform, their definition of lead quality, and the destination for enriched data.
Worth knowing: Call-tracking platforms vary, so most clients connect through the Custom API Bridge rather than a prebuilt connector. Audio transcription is not part of this capability.
What this capability does+
The problem
The dashboard says 200 leads. Sales says most were wrong-number calls and price shoppers. Nobody can prove which campaigns produced the real ones.
What the agent can do
—Pull call and lead records from the client’s tracking platform through approved access
—Classify lead quality against the client’s own definition of a good lead
—Attribute quality back to campaign, keyword or channel
—Write enriched quality data back to the approved destination
—Flag the campaigns spending into low-quality volume
Systems used
Custom APIAirtableGoogle Ads
Reusable across clients
The classification approach, the attribution join and the reporting shape are reused; the quality definition is per client.
Configured per workspace
The client's own call-tracking or lead platform, their definition of lead quality, and the destination for enriched data.
Where a human decides
Writes back to the tracking or CRM record require approval. The agent never contacts a lead.
Call-tracking platforms vary, so most clients connect through the Custom API Bridge rather than a prebuilt connector. Audio transcription is not part of this capability.
What we configure
—Approved access to the client’s tracking platform through the Custom API Bridge
—The quality classification rules and the attribution join
—The approved destination for enriched records
What you provide
—Which tracking platform and account belong to this workspace
—What a good lead actually looks like in their business
—Where enriched data should land
What a real proof looks like
One real month of leads classified, attributed back to campaign, and reconciled against what the sales team says actually happened.
Stop losing deals to a missed reply — every thread that needs an answer surfaced, with the draft already written.
GmailZoho CRMHubSpot
Read Analyze Draft Approval required
Human control ·
Drafts only. A person reads, edits and sends every message — the agent never sends mail on its own.
Per workspace ·
The client's own mailbox and approved scopes, which threads are in scope, the tone rules, and who sends.
Worth knowing: Draft-first by design. Sending requires an explicitly approved scope tier that many teams deliberately never grant — and this capability does not assume it.
What this capability does+
The problem
The reply that would have closed it is four days old and eleven threads down. Nobody is negligent; the inbox simply out-scaled the person.
What the agent can do
—Read approved threads and identify the ones awaiting a reply
—Rank by how long they have waited and what is at stake
—Draft a contextual reply grounded in the actual thread history
—Link the thread to the matching CRM record
—Leave every draft for a person to read, edit and send
Systems used
GmailZoho CRMHubSpot
Reusable across clients
The triage logic, the draft structure and the ranking rules are built once and reused across clients.
Configured per workspace
The client's own mailbox and approved scopes, which threads are in scope, the tone rules, and who sends.
Where a human decides
Drafts only. A person reads, edits and sends every message — the agent never sends mail on its own.
Draft-first by design. Sending requires an explicitly approved scope tier that many teams deliberately never grant — and this capability does not assume it.
What we configure
—Approved mailbox access scoped to this workspace and to the threads in scope
—Triage rules and tone constraints
—The CRM link and the approval boundary
What you provide
—Which mailbox belongs to this workspace
—Which threads are in scope and which are off limits
—Who sends
What a real proof looks like
One real week of threads triaged, drafts produced, and a person sending approved replies faster than they did before.
Operations stay inside the approved folder roots. Deletion and unrestricted sharing stay blocked unless that exact capability is enabled and proven.
Per workspace ·
The client's own Drive or Shared Drive, the approved folder roots, the naming convention, and who approves structural changes.
Worth knowing: Scoped to the approved folder roots. Blocked actions stay blocked — this is a file operations capability, not a DAM, a file manager, or a general storage tool.
What this capability does+
The problem
The agent writes the caption, the report and the brief — then a human spends the afternoon downloading, renaming and re-uploading files into the right client folder.
What the agent can do
—Find approved files and folders across My Drive and Shared Drives
—Upload, copy, move, rename and organise assets into the client’s structure
—Download and export files for downstream work, including media
—Map a messy folder tree and propose a clean structure
—Keep every operation scoped to the folders this workspace may touch
Systems used
Google Drive
Reusable across clients
The hygiene rules, the naming convention and the proposed structure template are defined once and applied per client.
Configured per workspace
The client's own Drive or Shared Drive, the approved folder roots, the naming convention, and who approves structural changes.
Where a human decides
Operations stay inside the approved folder roots. Deletion and unrestricted sharing stay blocked unless that exact capability is enabled and proven.
Scoped to the approved folder roots. Blocked actions stay blocked — this is a file operations capability, not a DAM, a file manager, or a general storage tool.
What we configure
—Approved Drive access scoped to this workspace and to specific folder roots
—Naming conventions and the target structure
—Which operations are allowed and which stay blocked
What you provide
—Which Drive or Shared Drive belongs to this workspace
—The folder roots agents may work inside
—Who approves moving or restructuring assets
What a real proof looks like
One real client folder tree mapped, one approved reorganisation carried out end to end, and one asset uploaded and placed correctly without a manual handoff.
Uploads land in the approved privacy state. Making a video public is an approved action, and channel-destructive operations stay blocked.
Per workspace ·
The client's own channel, the approved scopes, the metadata conventions, and who approves publishing.
Worth knowing: Scoped to the approved channel for this workspace. This is publishing and channel operations, not audience growth or content strategy.
What this capability does+
The problem
Long-form publishing is death by a thousand steps: download, re-upload, thumbnail, description, captions, playlist — on every client channel, every week.
What the agent can do
—Pull the finished video and thumbnail from the approved client folder
—Upload to the correct client channel with the right privacy state
—Set titles, descriptions, tags, captions and playlist placement
—Read back channel and video performance for reporting
—Hold the transition to public for approval
Systems used
YouTubeGoogle Drive
Reusable across clients
The metadata conventions, the upload checklist and the reporting shape are built once and reused per channel.
Configured per workspace
The client's own channel, the approved scopes, the metadata conventions, and who approves publishing.
Where a human decides
Uploads land in the approved privacy state. Making a video public is an approved action, and channel-destructive operations stay blocked.
Scoped to the approved channel for this workspace. This is publishing and channel operations, not audience growth or content strategy.
What we configure
—Approved YouTube access pinned to one channel per workspace
—Metadata conventions and the default privacy state
—The approval boundary for going public
What you provide
—Which channel belongs to this workspace
—Their metadata and naming conventions
—Who approves publishing
What a real proof looks like
One real video published end to end from an approved Drive folder — file, thumbnail, metadata, playlist — with a human approving the public transition.
Turn public web research into structured rows your team can actually work from, not a pile of tabs.
FirecrawlApifyAirtableGoogle Drive
Read Analyze Create Update
Human control ·
Read-oriented by nature. Writes land in an approved destination and low-confidence extractions are flagged rather than filled in.
Per workspace ·
The approved sources for this client, the field schema, and the destination the structured output lands in.
Worth knowing: Public sources only. Sites change shape and some block automated collection outright; the honest output includes what could not be extracted.
What this capability does+
The problem
Competitive and market research is done by hand into a spreadsheet, goes stale in a fortnight, and is never repeated the same way twice.
What the agent can do
—Crawl approved public sources and return clean content
—Extract the specific fields the workflow needs, with the source recorded
—Write structured results into the approved destination
—Flag missing or low-confidence fields instead of inventing them
—Re-run on a cadence and surface what changed
Systems used
FirecrawlApifyAirtableGoogle Drive
Reusable across clients
The extraction schema, the confidence rules and the change-detection logic are built once and pointed at different sources.
Configured per workspace
The approved sources for this client, the field schema, and the destination the structured output lands in.
Where a human decides
Read-oriented by nature. Writes land in an approved destination and low-confidence extractions are flagged rather than filled in.
Answer "what actually changed and why" from real search and analytics data, without a human exporting four CSVs first.
Google Search ConsoleGoogle AnalyticsGoogle Ads
Read Analyze Recommend Draft
Human control ·
Read and analyse only. This capability changes nothing in any property — it produces findings and drafts for review.
Per workspace ·
The client's own Search Console property and GA4 property, the approved scopes, and the metrics that define success for them.
Worth knowing: Findings are only as good as the property configuration underneath them. Sampling, filtered views and misconfigured conversions are called out rather than silently absorbed.
What this capability does+
The problem
Traffic moved and nobody can say why without a half-day of exports, and by then the client has already asked twice.
What the agent can do
—Read query, page, and indexing data for approved properties
—Read GA4 behaviour and conversion data for the same period
—Detect movements that matter against the property’s own baseline
—Attribute changes to pages, queries or channels with the evidence attached
—Draft the explanation a client can actually read
Systems used
Google Search ConsoleGoogle AnalyticsGoogle Ads
Reusable across clients
The anomaly detection, the attribution logic and the report shape are built once and reused across every property.
Configured per workspace
The client's own Search Console property and GA4 property, the approved scopes, and the metrics that define success for them.
Where a human decides
Read and analyse only. This capability changes nothing in any property — it produces findings and drafts for review.
Findings are only as good as the property configuration underneath them. Sampling, filtered views and misconfigured conversions are called out rather than silently absorbed.
What we configure
—Approved Search Console and GA4 access scoped to this workspace
—Baselines and the anomaly thresholds
—The report shape and its cadence
What you provide
—Which properties belong to this workspace
—Which metrics actually define success
—Any known measurement caveats
What a real proof looks like
One real traffic movement explained from live data, with the attribution checked by whoever normally investigates it.
Client reports drafted from live data every week, led by the metric the client actually cares about.
Google AdsMetaGoogle AnalyticsGoogle Search Console
+1 more
Read Analyze Draft Approval required
Human control ·
Draft only. A person reviews and sends every report — the agent never sends anything to a client.
Per workspace ·
The client's own accounts and properties, their success metric, their reporting period, and who reviews and sends.
Worth knowing: A draft, not a finished client deliverable. Cross-channel attribution is reported honestly as separate channel views rather than merged into a single number nobody can defend.
What this capability does+
The problem
Reporting week eats two days. The same exports, the same charts, the same commentary, multiplied by every client on the roster.
What the agent can do
—Pull the period’s data from every approved channel for this client
—Lead the report with the client’s real success metric, not a template
—Flag anomalies and explain them in plain language
—File the draft into the client’s approved review folder
—Leave sending to a human, every time
Systems used
Google AdsMetaGoogle AnalyticsGoogle Search ConsoleGoogle Drive
Reusable across clients
The report structure, the anomaly logic and the plain-language explanations are built once and reused across the roster.
Configured per workspace
The client's own accounts and properties, their success metric, their reporting period, and who reviews and sends.
Where a human decides
Draft only. A person reviews and sends every report — the agent never sends anything to a client.
A draft, not a finished client deliverable. Cross-channel attribution is reported honestly as separate channel views rather than merged into a single number nobody can defend.
What we configure
—Approved access to every reporting source for this workspace
—The report structure and the client’s success metric
—The review folder and the approval boundary
What you provide
—Which accounts and properties belong to this workspace
—The metric the client is actually judged on
—Who reviews and sends
What a real proof looks like
One real client report drafted from live data and sent by a human, in materially less time than the manual version took.
Keep the systems your team actually runs on agreeing with each other, without a nightly manual export.
Airtablen8nCustom API
Read Analyze Create Update Approval required
Human control ·
Writes land only in approved destinations. Bulk overwrites require approval and destructive operations stay blocked.
Per workspace ·
The client's own bases, tables and automations, which system is authoritative for which field, and who approves a reconciliation.
Worth knowing: Airtable read and write are the strong path. n8n is read-only through the bridge today — workflows can be monitored but not created or modified — so orchestration changes remain a human action in the n8n editor.
What this capability does+
The problem
Two systems disagree, both are half right, and reconciling them is a recurring manual export that only one person on the team knows how to do.
What the agent can do
—Read the current state of approved records across systems
—Detect divergence between systems and name the specific rows
—Write reconciled data to the approved destination
—Read automation and execution state for monitoring
—Flag failures with enough context to act on them
Systems used
Airtablen8nCustom API
Reusable across clients
The reconciliation logic, the divergence rules and the failure reporting are built once and pointed at each client’s systems.
Configured per workspace
The client's own bases, tables and automations, which system is authoritative for which field, and who approves a reconciliation.
Where a human decides
Writes land only in approved destinations. Bulk overwrites require approval and destructive operations stay blocked.
Airtable read and write are the strong path. n8n is read-only through the bridge today — workflows can be monitored but not created or modified — so orchestration changes remain a human action in the n8n editor.
What we configure
—Approved access to each system in scope for this workspace
—Which system is authoritative for which field
—The approval boundary for reconciliation writes
What you provide
—Which bases, tables and automations belong to this workspace
—Which system wins when two disagree
—Who approves a reconciliation run
What a real proof looks like
One real divergence detected between two live systems, reconciled with approval, and the same check running clean on the next cycle.
The allowed methods and paths are set per connection. Destructive operations are gated, and anything outside the approved host is refused before it is sent.
Per workspace ·
The client's own API, its base URL and auth scheme, the allowed methods, and who approves writes.
Worth knowing: Requires the target system to have an API worth using. Undocumented or unstable APIs are a real risk and are validated before anything depends on them.
What this capability does+
The problem
The one system that matters most to this client has no connector anywhere, so the workflow stops at the exact point it becomes valuable.
What the agent can do
—Connect any approved API through the Custom API Bridge
—Read data from the client’s own system on a defined path
—Write approved changes back within the allowed methods
—Keep every call scoped to the approved host for that workspace
—Leave a redacted record of every attempt
Systems used
Custom API
Reusable across clients
The connection pattern, the proof path and the review checklist are the same every time — only the API changes.
Configured per workspace
The client's own API, its base URL and auth scheme, the allowed methods, and who approves writes.
Where a human decides
The allowed methods and paths are set per connection. Destructive operations are gated, and anything outside the approved host is refused before it is sent.
Requires the target system to have an API worth using. Undocumented or unstable APIs are a real risk and are validated before anything depends on them.
What we configure
—The approved connection, base URL, auth scheme and allowed methods
—A safe proof path to confirm access before real work
—The approval boundary for writes
What you provide
—Which system and which account belong to this workspace
—API documentation, or someone who knows the system
—Who approves writes
What a real proof looks like
One safe read against the client’s real API succeeding through approved access, then one approved write doing something the team actually needed.
Surface the deals that stalled quietly — the pipeline that was already paid for and then forgotten.
Zoho CRMHubSpotAirtable
Read Analyze Recommend Draft Approval required
Human control ·
Nothing is sent and no record is changed without a named human approving it. The agent produces a reviewed list, not activity.
Per workspace ·
The client's own CRM, the pipeline definitions, what counts as stalled in their sales cycle, and who owns re-engagement.
Worth knowing: Runs as a scoped pilot first. Stall thresholds are meaningless until they are calibrated against one real pipeline, and every CRM models stages differently.
What this capability does+
The problem
Deals go quiet and nobody notices. The pipeline that was already paid for in ad spend sits untouched while the team chases new leads.
What the agent can do
—Identify opportunities that stalled against their own stage-velocity baseline
—Separate genuinely dead deals from deals nobody followed up on
—Rank recoverable pipeline by value and recency
—Draft a re-engagement approach per deal with the history attached
—Hold every outbound message and every record change for approval
Systems used
Zoho CRMHubSpotAirtable
Reusable across clients
The stall-detection logic, the ranking model and the review format carry across clients; the thresholds are tuned per pipeline.
Configured per workspace
The client's own CRM, the pipeline definitions, what counts as stalled in their sales cycle, and who owns re-engagement.
Where a human decides
Nothing is sent and no record is changed without a named human approving it. The agent produces a reviewed list, not activity.
Runs as a scoped pilot first. Stall thresholds are meaningless until they are calibrated against one real pipeline, and every CRM models stages differently.
What we configure
—Approved CRM access scoped to this workspace
—Stall thresholds calibrated against the client’s real sales cycle
—The approval boundary for outreach and record changes
What you provide
—Which CRM and which pipeline belong to this workspace
—What "stalled" means in their business
—Who owns re-engagement and signs off on it
What a real proof looks like
One real pipeline analysed, one ranked recovery list reviewed with the sales owner, and one approved re-engagement sent by a human.
Keep outbound sequences supplied with researched, relevant prospects instead of scraped noise.
InstantlyAirtableFirecrawlApify
Read Analyze Draft Create Approval required
Human control ·
Nothing sends without approval. Sequence activation is a human action, always.
Per workspace ·
The client's own sending account and domain, their ICP definition, messaging rules, and who approves a send.
Worth knowing: Runs as a scoped pilot. Deliverability, domain reputation and compliance are the client’s own risk surface and are reviewed before any sequence goes live.
What this capability does+
The problem
Outbound dies from generic personalisation. Real research per prospect does not scale by hand, so teams send worse messages to more people.
What the agent can do
—Research target accounts from approved public sources
—Structure findings into the fields the sequence actually personalises on
—Draft per-prospect personalisation grounded in the research, not invented
—Stage sequences and prospect batches for review
—Hold every send for approval
Systems used
InstantlyAirtableFirecrawlApify
Reusable across clients
The research structure, the personalisation framework and the review checklist carry across clients.
Configured per workspace
The client's own sending account and domain, their ICP definition, messaging rules, and who approves a send.
Where a human decides
Nothing sends without approval. Sequence activation is a human action, always.
Runs as a scoped pilot. Deliverability, domain reputation and compliance are the client’s own risk surface and are reviewed before any sequence goes live.
What we configure
—Approved access to the sending platform and research sources
—The ICP definition and the personalisation framework
—The approval boundary before any send
What you provide
—Which sending account and domain belong to this workspace
—Their ICP and their messaging rules
—Who approves a sequence going live
What a real proof looks like
One researched batch, reviewed by the client, with one approved sequence sent by a human and reply quality compared against the previous batch.
Nothing is published from this capability. Every piece stops for editorial review, and claim rules are checked before review, not after.
Per workspace ·
The client's own brand voice, claim restrictions, folder structure, production board, and who approves content.
Worth knowing: Runs as a scoped pilot. Content quality depends entirely on how well the client’s voice and claim rules are captured first — that calibration is the pilot.
What this capability does+
The problem
Content is drafted in one tool, assets live in another, status lives in a third, and a human spends more time moving it than making it.
What the agent can do
—Read the brief and the client context before drafting anything
—Produce drafts that follow the client’s approved voice and claim rules
—File assets into the right client folder with the right name
—Update the production board so status reflects reality
—Stage everything for human review before anything is published
Systems used
Google DriveAirtableOpenAIAsana
Reusable across clients
The pipeline structure, the brief template and the review gates are built once; the voice and claim rules are per client.
Configured per workspace
The client's own brand voice, claim restrictions, folder structure, production board, and who approves content.
Where a human decides
Nothing is published from this capability. Every piece stops for editorial review, and claim rules are checked before review, not after.
Runs as a scoped pilot. Content quality depends entirely on how well the client’s voice and claim rules are captured first — that calibration is the pilot.
What we configure
—Approved access to the content, asset and board systems for this workspace
—The brief template, voice rules and claim restrictions
—The review gates before anything reaches a client
What you provide
—Their brand voice and what they may not claim
—The folder structure and production board for this workspace
—Who approves content
What a real proof looks like
One real piece taken from brief to ready-for-review with assets filed and the board accurate, reviewed by the editor who normally does it by hand.
Nothing runs as an ad from this capability. Every concept goes to creative review, and approved brand assets are used as supplied — never redrawn or reinvented.
Per workspace ·
The client's own brand assets, claim restrictions, review folder, and who approves creative.
Worth knowing: Runs as a scoped pilot. Generated concepts are for review and iteration, not finished production assets, and every visible claim is checked against the client’s approved rules.
What this capability does+
The problem
Creative briefs get written from opinion because pulling the performance evidence together takes longer than writing the brief.
What the agent can do
—Read what is currently working and what is fatiguing in the account
—Write a creative brief grounded in that evidence rather than in taste
—Produce concept variations using the client’s approved brand assets
—File concepts into the client’s review folder with consistent naming
—Stage everything for creative review before anything runs
Systems used
OpenAIGoogle DriveMeta
Reusable across clients
The brief structure, the evidence-to-brief logic and the review flow carry across clients; brand assets never do.
Configured per workspace
The client's own brand assets, claim restrictions, review folder, and who approves creative.
Where a human decides
Nothing runs as an ad from this capability. Every concept goes to creative review, and approved brand assets are used as supplied — never redrawn or reinvented.
Runs as a scoped pilot. Generated concepts are for review and iteration, not finished production assets, and every visible claim is checked against the client’s approved rules.
What we configure
—Approved access to the performance data, the brand assets and the review folder
—The brief template and the claim rules that constrain it
—The review gate before anything is produced for real
What you provide
—Their approved brand assets and how they may be used
—What they may not claim
—Who approves creative
What a real proof looks like
One real brief produced from actual account evidence, concepts filed for review, and a creative lead confirming the brief was usable as written.
Nothing is posted publicly without approval. Escalations and complaints are routed to a person rather than answered automatically.
Per workspace ·
The client's own Pages and professional accounts, approved scopes, tone rules, escalation contacts, and who approves public replies.
Worth knowing: Runs as a scoped pilot, and covers public comment surfaces only. Meta scope approval is its own process per app. Private inbox access is a separate, planned capability — see Meta Community Inbox.
What this capability does+
The problem
Community management is the first thing dropped when the team is busy, and the first thing a client notices when it slips.
What the agent can do
—Read public comments and interactions on approved Pages and accounts
—Triage by intent — question, complaint, lead, spam, escalation
—Draft responses in the client’s approved voice
—Surface anything that needs a human immediately
—Hold every public response for approval
Systems used
FacebookInstagramMeta
Reusable across clients
The triage taxonomy, the response framework and the escalation rules are built once and reused per client.
Configured per workspace
The client's own Pages and professional accounts, approved scopes, tone rules, escalation contacts, and who approves public replies.
Where a human decides
Nothing is posted publicly without approval. Escalations and complaints are routed to a person rather than answered automatically.
Runs as a scoped pilot, and covers public comment surfaces only. Meta scope approval is its own process per app. Private inbox access is a separate, planned capability — see Meta Community Inbox.
What we configure
—Approved Meta access scoped to the Pages and accounts for this workspace
—The triage taxonomy, tone rules and escalation routing
—The approval boundary before anything is posted
What you provide
—Which Pages and accounts belong to this workspace
—Their tone rules and escalation contacts
—Who approves a public reply
What a real proof looks like
One real week of comments triaged, responses drafted, escalations surfaced correctly, and a community manager approving and posting.
Publish an approved piece to several client channels without rebuilding the connection for each one.
MetaYouTubeCustom APIGoogle Drive
Read Draft Create Publish Approval required
Human control ·
Publication is a single approved human decision across all destinations. Nothing goes live channel by channel without it.
Per workspace ·
The client's own channels and accounts per destination, the approved scopes for each, and who approves publishing.
Worth knowing: Runs as a scoped pilot, and the channel mix is the variable. Every additional destination is its own connector with its own approval process — this is not a universal publishing bus.
What this capability does+
The problem
The same approved asset has to reach four channels, and each one has a different format, a different auth model and a different failure mode.
What the agent can do
—Take an approved asset from the client’s folder
—Adapt format and metadata per destination channel
—Stage the post on each approved channel
—Hold publication for a single approval decision
—Read back per-channel results for reporting
Systems used
MetaYouTubeCustom APIGoogle Drive
Reusable across clients
The adaptation rules and the approval flow are built once; each destination channel is connected per client.
Configured per workspace
The client's own channels and accounts per destination, the approved scopes for each, and who approves publishing.
Where a human decides
Publication is a single approved human decision across all destinations. Nothing goes live channel by channel without it.
Runs as a scoped pilot, and the channel mix is the variable. Every additional destination is its own connector with its own approval process — this is not a universal publishing bus.
What we configure
—Approved access per destination channel for this workspace
—Format and metadata adaptation rules per channel
—The single approval gate before anything publishes
What you provide
—Which channels and accounts belong to this workspace
—Format and tone requirements per channel
—Who approves publishing
What a real proof looks like
One approved asset published to the client’s real channel set from a single approval, with per-channel results read back.
Make the board tell the truth again — stale tasks classified, real blockers surfaced, approvals routed to the right person.
AsanaClickUpAirtable
Read Analyze Recommend Update Approval required
Human control ·
Board changes require approval. Task deletion is blocked, and low-confidence classifications are surfaced rather than acted on.
Per workspace ·
The client’s or team’s own board, what “done” means in their process, the escalation chain, and who approves closing work.
Worth knowing: Runs as a scoped pilot. Board conventions differ wildly between teams, and a classifier tuned on the wrong convention produces confident nonsense — so calibration comes first.
What this capability does+
The problem
The board stopped reflecting reality months ago. Everyone knows it, nobody has a spare afternoon to fix it, and status meetings fill the gap.
What the agent can do
—Classify every open task with a confidence level and the evidence behind it
—Produce a high-confidence "propose to close" batch
—Surface genuine blockers rather than everything that looks old
—Route approval requests to the person who actually owns the decision
—Apply approved status changes only
Systems used
AsanaClickUpAirtable
Reusable across clients
The classification model, the confidence thresholds and the escalation logic are built once and reused across boards.
Configured per workspace
The client’s or team’s own board, what “done” means in their process, the escalation chain, and who approves closing work.
Where a human decides
Board changes require approval. Task deletion is blocked, and low-confidence classifications are surfaced rather than acted on.
Runs as a scoped pilot. Board conventions differ wildly between teams, and a classifier tuned on the wrong convention produces confident nonsense — so calibration comes first.
What we configure
—Approved board access for this workspace
—The classification model calibrated to this team’s conventions
—The escalation chain and the approval boundary
What you provide
—Which board belongs to this workspace
—What "done" and "blocked" mean in their process
—Who approves closing work
What a real proof looks like
One real board classified, one propose-to-close batch reviewed by the owner, and the accepted rate high enough to trust the next run.
Know what the agency is actually paying for, which client it belongs to, and what quietly renewed last month.
Custom APIAirtable
Read Analyze Recommend Draft
Human control ·
Read and analyse only. Nothing is cancelled, purchased or changed — the output is a review for a person who holds the budget.
Per workspace ·
The agency’s own billing sources, the attribution model, and who owns the software budget.
Worth knowing: No standard path exists. Billing data lives in a different combination of systems at every agency, so this is scoped as a build after an assessment rather than presented as ready.
What this capability does+
The problem
Nobody can say what the agency spends on software, which client it should be billed to, or what renewed last month without anyone deciding to renew it.
What the agent can do
—Read subscription and billing data from approved sources
—Attribute spend to the client or internal function it belongs to
—Surface renewals, duplicates and unused seats
—Draft the internal review a finance owner can act on
Systems used
Custom APIAirtable
Reusable across clients
The attribution model and the review format would be built once — but the source systems differ per agency, which is what makes this custom.
Configured per workspace
The agency’s own billing sources, the attribution model, and who owns the software budget.
Where a human decides
Read and analyse only. Nothing is cancelled, purchased or changed — the output is a review for a person who holds the budget.
What backs this up
Nothing is published for this capability yet — which is exactly why it is not marked as available.
What is still limited
No standard path exists. Billing data lives in a different combination of systems at every agency, so this is scoped as a build after an assessment rather than presented as ready.
What we configure
—Scoped after an assessment — the source systems determine the build
What you provide
—Which billing and subscription systems are in scope
—How spend should be attributed
—Who owns the software budget
What a real proof looks like
Defined during the assessment. Nothing is claimed as proven for this capability today.
Private-message handling across Meta surfaces — listed here so the gap is explicit rather than implied.
Meta Community Inbox
Read Draft Approval required
Human control ·
Not applicable — this capability is not available and no setup path is offered.
Per workspace ·
Not applicable — nothing is configured for this capability today.
Worth knowing: Planned, not available. Private inbox access carries its own permission, review and data-handling requirements, and none of them are in place. Do not plan client work around this capability.
What this capability does+
The problem
Private messages are where a lot of real client conversation happens, and handling them at agency scale is genuinely hard.
What the agent can do
—Not available today
Systems used
Meta Community Inbox
Reusable across clients
Not applicable — this capability is not available today.
Configured per workspace
Not applicable — nothing is configured for this capability today.
Where a human decides
Not applicable — this capability is not available and no setup path is offered.
What backs this up
Nothing is published for this capability yet — which is exactly why it is not marked as available.
What is still limited
Planned, not available. Private inbox access carries its own permission, review and data-handling requirements, and none of them are in place. Do not plan client work around this capability.
What a real proof looks like
None. Nothing has been proven for this capability, and no pilot is offered.
Planned — no setup path today
No workflow matches that search.
Most agency work is a combination of what is here pointed at a system we have not built a
path for yet. Tell us the workflow and the systems it touches.
Product names and logos are trademarks of their respective owners. Outloop is not affiliated
with, endorsed by, or a partner of these companies. Marks indicate compatibility only.
What each status means
Available with guided setup
The access path is documented and evidenced. Setup is guided: the client accounts, resources, context and approval rules are still configured per workspace.
Limited guided pilot
The path is workable and we run it as a scoped pilot with your team first, rather than presenting it as routine.
Custom workflow
No standard path exists yet. Scoped as a build after an assessment, not implied to be ready.
Released platform capability
Part of the Outloop runtime. Included in every workspace — not an add-on and not sold separately.
Planned
Not available. Listed so the gap is explicit rather than implied. No setup path is offered today.
Built into every Outloop workflow
3 capabilities are part of the Outloop runtime itself. They are
included in every workspace — not add-ons, not downloadable Skills, and not priced per
workflow.
Released platform capability
Organization Contacts and Workspace Context
Every agent starts from approved client knowledge — who to contact, the brand rules, what may not be claimed — instead of guessing.
Worth knowing: Context is only as good as what has been approved into it. An empty workspace returns nothing rather than inventing an answer — which is the correct behaviour, and sometimes a surprising one.
Agents propose what they learned; nothing changes until a person approves it.
Worth knowing: It creates a review queue that somebody has to actually work. Learning that is never reviewed is learning that never applies — that is the deliberate trade.
Bring a new client workspace online with its own approved access, resources, context and approval rules.
Worth knowing: Approved access setup is what carries over between environments. Skills, memory, templates and runtime configuration do not migrate between agent platforms, and this capability does not claim they do.
Grouped by what is actually true today. Every connection is set up once and granted to the
client workspaces that should have it — agents use the access without ever receiving the
credential.
Proven or strongly evidenced paths
The access path is documented on this site, with a published setup guide or proof page you can read before you commit to anything.
Proven or strongly evidenced paths
System
Status
What agents do
Setup
Google Ads
Documented path
Read campaign, search-term and spend data; propose changes for approval
The API exists and the path is workable. Connector-specific setup — scopes, app review, account structure — is validated with your team rather than presented as routine.
Guided or connector-specific validation required
System
Status
What agents do
Setup
Google Merchant Center
Validated with you
Read product feed and disapproval data; prepare feed corrections
—
Facebook
Validated with you
Read and draft Page content within approved scopes
—
Instagram
Validated with you
Read and draft professional-account content within approved scopes
—
WhatsApp Business Platform
Validated with you
Send approved template messages through the Cloud API
Generate approved creative assets and text through an approved account
—
Planned
Not available. Listed so the gap is explicit rather than implied. No setup path is offered today.
Planned
System
Status
What agents do
Setup
Meta Community Inbox
Planned
Not available. No setup path is offered today.
—
Product names and logos are trademarks of their respective owners. Outloop is not affiliated
with, endorsed by, or a partner of these companies. Marks indicate compatibility only.
Build it once. Keep every client separate.
The reusable workflow stays consistent. Each client Workspace
keeps its own accounts, resources, permissions, Context, KPIs, and approval rules.
01
Reusable organization layer
The workflow itself — the logic, the rules, the report shape, the review checklist. Built once, and the same for every client.
02
Workspace-specific client layer
Each client workspace keeps its own accounts, resources, permissions, Context, KPIs and approval rules. Nothing here is shared, and nothing crosses between clients.
03
Outloop Runtime layer
Approved access is used host-side. Agents never receive the credential, wrong-client access is refused by policy before any backend call, and every attempt is written to a redacted local audit log.
04
Human-control layer
Who approves what, and where an action stops until a person says yes. Destructive operations stay blocked unless that exact capability has been enabled.
What this does not mean. Not unlimited
clients, not unlimited agents, and not a guarantee of availability. Capacity is what your plan
reserves — see pricing.
How a capability becomes real client work
A Forward Deployed Engineer validates the workflow against your real environment, configures
approved access, implements it, and trains your team — then you decide whether to roll it out
to more client workspaces.
01
Pick the workflow
One real capability you want running for a real client — not a platform migration.
02
Map the access
Which accounts, resources, scopes and approvals it needs, and where it currently breaks.
03
Configure and implement
Approved access set up once, scoped to the right client workspace, and the workflow built against your real environment.
04
Reach a real proof
A working result on one real client, with approvals honoured and the attempt audited.
What happens when an agent requests approved access
01
Agent request
The agent asks for an approved action or alias — not a raw key.
02
Policy & tenant check
Outloop checks project, tenant identity, and runtime policy before anything runs.
03
Local broker
On approval, the local broker uses the credential on the wire to perform the call.
04
Redacted result
The agent receives a sanitized, non-secret result. Raw values never enter its context.
05
Audit log
Every attempt is written to a redacted local audit — decision, tenant, service.
The agent never sees the credential. A wrong-tenant request is denied at the policy check, before any backend call.
Nothing client-specific is collected on this website.
Account identifiers, credentials, resource selections and client data are configured
directly in your own Outloop installation — never through a web form.
A Skill is a reusable, downloadable operating package. A Capability is the complete business
workflow — it can involve several Skills, connected systems, workspace configuration and
approvals. One downloadable Skill is never the whole Capability.
The public Skill library
Ready-to-download Skill packages: direct ZIP downloads, no email required. Add one to a compatible agent environment, select the relevant Outloop Workspace, and run it.
Five read-only or draft-only starter Skills, bundled with the AI Marketing Agency
Operating Playbook. Not the catalog — a safe way to see how an agent skill behaves before
any access is configured.
No. They are approved workflow patterns that run on one access layer. What differs between them is which systems they touch, which actions they take, and where a human has to approve something — not which product you bought.
The access path is documented and evidenced on this site, and setup is guided rather than self-serve. It does not mean the workflow arrives preconfigured for your clients: the accounts, resources, context and approval rules are still set up per client workspace.
The path is workable, but we scope it as a pilot with your team before treating it as routine. Usually that is because thresholds, conventions or platform review differ so much between clients that a claim of "it just works" would be false.
Meta Community Inbox is listed so the gap is explicit rather than implied. It is not available, no setup path is offered, and it carries no request or purchase option. Do not plan client work around it.
A Capability is the complete business workflow — it can involve several Skills, connected systems, workspace configuration, approvals and implementation work. A Skill is a single reusable, downloadable operating package. Some Capabilities have downloadable Skills you can get right now from the Skill library; others do not.
No. There is no checkout, no cart and no activation on this page. Your Outloop subscription covers the runtime, workspaces, approved access, policy and audit. Implementing a specific workflow for your environment is scoped separately.
The reusable workflow stays consistent. Each client workspace keeps its own accounts, resources, permissions, context, KPIs and approval rules — so the same workflow runs for client eleven without being rebuilt, and without client eleven ever reaching client three’s data.
Every capability states its own control boundary on the card, and the detail panel lists the specific actions that stop for approval. Destructive operations are gated separately and stay blocked unless that exact capability has been enabled and proven.
No. Agents request an approved action; the credential is used host-side and never reaches the agent. Wrong-client access is refused by policy before any backend call, and every attempt is written to a redacted local audit log.
Most agency work is a combination of what is here pointed at a system we have not built a path for yet. Tell us the workflow and the systems it touches and we will say honestly whether it is configuration, a connector build, or not a fit.
Ready to get out of the API loop?
Run more client AI workflows without rebuilding API access every time.
Connect API access once and reuse it across every client workspace — instead of rebuilding setup for each new one.