Automations and Content Loops

Reports and tickets are the weekly loop. Automations are for work that should happen without a weekly human pass: a job that acts through the tools you have greenlit, a loop that turns a data source into a stream of content, or a script that syncs data on a schedule. Turn these on after the weekly loop produces tickets you trust.

Automations are included with Cloud. If you do not see New Automation or Content from data under Reports → Create new, contact support or your onboarding contact.

Autonomous Operator jobs

An operator job is a scheduled agent with a short list of granted write tools. Reports → Create new → New Automation opens "Create Autonomous Operator Job":

• Job name and operator instructions: what to check and what to do.
• Autonomous operator toggle.
• Integration and tool: the write action the job may take, optionally pinned to one fixed value such as a Discord channel or a campaign.

The job is created disabled, scheduled for Monday mornings in your browser's timezone. Open its Settings to change the schedule and Timezone, edit each grant's label and pinned fields, or remove extra grants. A schedule fires at most once an hour, and an automation needs a schedule before it can be enabled.

A job can have several write tools, each narrow and pinned where the target should never change. Adding more than the first, or listing read tools explicitly, is done through the in-app chat or the create_automation / update_automation tools, not the create dialog.

Pre-approved tools. Each run gets a fixed tool list and nothing else: the granted write tools, plus read tools. By default the read tools are those on the granted integrations whose names start with get, list, search and similar, or that the integration marks read-only (and not destructive). You can also name the read tools explicitly. The list is shown on the automation and returned by list_automations.

Each run is recorded as a ticket, so the board shows what the job did and the analysis step evaluates it. Runs use the workspace's credits like any agent run. The first run starts as soon as you create the job.

What operator jobs are good for:

• Posting a daily "what we shipped" summary to a Discord channel (a built-in template, Shipped Announcement, does exactly this).
• Keeping negative keyword lists updated from search-term reports.
• Pausing ads that breach a cost-per-lead ceiling, with the pause tool granted and nothing else.
• Filing a ticket when a metric moves beyond a threshold.

Grants and their pinned values are enforced at call time inside the execution engine, not only in the prompt, so an instruction cannot talk the job into a tool or a target it was not given. Start with a read-mostly job and one low-risk write, watch the tickets it creates for a week, then widen.

From an agent or the CLI. The same jobs can be built without the dashboard: create_automation, update_automation, list_automations, run_automation (with a dry_run that takes no write actions) and get_automation_run are on the Cogny MCP server and the Cogny CLI.

Your own app. If the data or action lives in your own app, expose it as an MCP endpoint and register it as a custom MCP server; the automation then calls it like any integration. See Connect your own app to Cogny automations.

Content from data loops

A content loop turns a source into individual pieces, one ticket each. Reports → Create new → Content from data. The wizard shows a preview of the source rows, produces a test piece first, and nothing is published until you turn the schedule on.

Sources

• A BigQuery table in your warehouse (a daily summary, a product feed, an event list). You pick the cursor column that identifies new rows.
• An RSS or Atom feed: news, releases, a partner's blog.
• A document in the context tree, split into sections, each becoming a piece from a different angle.
• Best-performing pages from Search Console, to localise winners into other languages.
• Custom SQL for advanced cases.

Keywords for each piece come from a context-tree node (a keyword plan), Search Console's top queries, Google Ads keyword ideas, or the writer's own choice.

Publish targets: a table in your Supabase project, a WordPress or Ghost draft, Webflow, Framer or Sanity, a Shopify blog article, a Lovable site, or a GitHub repository through the coding agent as a pull request.

Limits and safety: at most five pieces per run, the last 200 source rows are considered, and the loop remembers what it has already covered so nothing is published twice. Three consecutive source failures pause the loop. Each piece is a ticket, so you can keep approval on the ticket or let YOLO handle pieces above your threshold.

The flagship pattern is the SEO and localisation loop: produce content, watch Search Console for what ranks, rewrite titles and descriptions to match, add product links and calls to action once clicks arrive, then clone the winners into other languages. A Nordic apparel brand went from about 50 ranking articles to translations in dozens of languages this way, with organic becoming the main revenue channel. Doing that by hand on a thousand pages is impossible; in Cogny it is a couple of approvals a week.

A programmatic example: a platform's own backend rows (projects, listings, releases), classified and turned into one how-to page each, published to the repository.

Paid-to-crawl for new pages

Google crawls a fresh domain rarely. If you launch many new pages, buy a small amount of traffic into them (Google, X or LinkedIn) to raise crawl budget. Expect two to three months for a new domain versus weeks on an established one. This is a strategy note for the growth strategy field, not a feature.

Scripts

Scripts are deterministic JavaScript jobs with no language model in the loop, for work that loops are too slow and expensive for: a nightly export into BigQuery, a backfill, a cursor-based sync from an API. They run in a sandbox with access only to the Cogny SDK: read tools always, write tools only with a grant, your own BigQuery, and a small state store.

Scripts are feature-flagged per workspace and managed through chat or MCP tools rather than a page: the agent creates the script, dry-runs it, you enable it. Failures do not retry silently; they file one deduplicated ticket with the error, the log tail and a sample payload, and the schedule pauses after three consecutive failures. With auto-repair on, the ticket is pre-approved for the agent with just enough tools to fix the script. Scripts are not metered.

Ask for Scripts if you find yourself wanting a nightly sync of something into your warehouse.

Solo loops

Solo-tier workspaces have a lighter loop feature designed for a single operator with their own agent. It is not part of Cloud; Cloud uses operator jobs and content loops described above.