<!-- Cogny documentation. Canonical page: https://cogny.com/docs/growth-tickets-architecture -->

# How Growth Tickets Work

How Cogny turns report insights into prioritised, executable tickets: what the ticket agent reads, how it scores and de-duplicates, how execution and analysis close the loop, and what always stays with a human.

**Author:** Cogny Team  
**Published:** 2025-02-21  
**Updated:** 2026-10-09  
**Canonical:** https://cogny.com/docs/growth-tickets-architecture

Growth tickets are the unit of work in Cogny. A ticket is one proposed experiment, written up as a brief a human can judge in a minute, executed by an agent, the coding agent or a person once approved, and measured afterwards. This page describes how the system behaves end to end. For the day-to-day of working the board, see [Tickets and Approvals](/docs/tickets-and-approvals).

## The loop

1. **Reports produce insights.** Scheduled reports read your data and context and end with recommended actions for the week.
2. **A ticket agent turns insights into briefs.** On a schedule, and whenever you press Generate Tickets, a second agent reads the recent reports and writes each worthwhile recommendation up as a ticket.
3. **A human decides.** Approve, refine or reject with a reason.
4. **Execution happens through the right channel.** An integration, the coding agent as a pull request, or a person on your team.
5. **Analysis measures the outcome** once enough data exists, and the result is written back so the next round of reports and tickets knows what worked.

Everything below is detail on those five steps.

## What the ticket agent reads before it writes

The ticket agent does not see a report in isolation. Its context includes:

- The recent reports and their recommended actions.
- Your growth strategy, company, industry and competitor context, and the ideal customer profile.
- Your core metrics, so proposals are framed against the numbers you run on.
- The ticket history: what was approved, what was rejected and why, the structured feedback on earlier tickets, and the evaluations of finished ones.
- Organisational memory, the running summary the agent maintains of what it has already said and learned.

This is why rejections with a reason matter. "We already did this in March" or "we are B2B, not consumer" becomes part of what the agent reads before proposing anything similar.

## What a ticket contains

A brief, not a headline. Every ticket carries the source reports it came from, the integration and tools it would use, the expected outcome, and the full specification for its type: for a paid campaign, the account, campaign settings, ad groups with keywords and negatives, destination URL, headlines and descriptions; for a page, the URL, headline, sections, calls to action, schema and design notes; for a manual task, the steps and the metric to watch.

Each ticket has one execution target, chosen when it is written:

- **Agent**: executed through a connected integration's tools.
- **Code**: executed by the coding agent as a pull request against your repository.
- **Manual**: executed by a person, who records the outcome.

## Prioritisation and de-duplication

Proposals are ranked by expected impact on your core metrics and the effort involved, and the agent keeps the batch short rather than exhaustive. Before a ticket is filed it is checked against the open board and the recent history so the same idea is not proposed twice, and against past rejections so a rejected idea does not return unless the data has changed. Feedback flags such as "already done", "duplicate" or "incorrect data" feed this check directly.

## Approval scoring and auto-execution

Every ticket gets an approval-likelihood score from 0 to 100, based on how you have decided on similar tickets before and on the quality of the brief itself. The score is shown on the card and drives YOLO mode: when enabled, tickets above your confidence threshold are approved automatically. Two rules apply regardless of threshold. A ticket only auto-executes when every tool it uses is read-only or explicitly granted for that job, so budget changes, campaign edits and audience mutations stay behind a human unless you have granted that specific action. And code tickets never auto-merge; a pull request always needs a person.

## Lifecycle

Tickets move through New, Assigned, In Progress, Review, Analysis, Done and Rejected. Approval starts execution. Code tickets wait in Review with a preview deployment and a visual proof report until the pull request is merged; the merge webhook moves them on. Executed tickets go to Analysis, where the agent waits for data, evaluates the result against the expected outcome, and reschedules itself if data is thin. Done tickets carry an evaluation (success, partial, failed or inconclusive) and notes on what to change, which is what the next generation reads.

Tickets you create yourself follow the same path: describe the goal, let the agent split it into briefs, approve the ones you want.

## Other ways tickets are created

- **Review Meeting** records a discussion; the notes go to the context tree and each action item becomes a ticket.
- **Content loops** create one ticket per piece for a data source or feed, so publishing stays reviewable.
- **Autonomous Operator jobs** record every run as a ticket, which is how a scheduled job stays auditable.
- **Your own agent** can list, create, update and comment on tickets over MCP.

## Audit and safety

Every write an executing ticket makes through an integration is recorded in the MCP write ledger with the tool, arguments and timestamp. Every ticket keeps its brief, execution log, evaluation and feedback. Cogny Shield can mask personal data in the results the agent reads and quarantine instruction-like text coming back from an integration, so a product description or support message cannot steer a ticket.

## Models

Cogny does not depend on one model. It continuously tests and evaluates the best model for each purpose in the workflow, including ticket generation, approval scoring, execution and analysis, on its own benchmark of marketing-analytics problems, and routes each step accordingly. Workspaces that need data to stay in Europe can run on EU-hosted options.

## Related

- [Tickets and Approvals](/docs/tickets-and-approvals): working the board day to day
- [Growth Tickets API](/docs/growth-tickets-api-reference): reading and writing tickets programmatically
- [How AI Reports Work](/docs/ai-report-generation-how-it-works): where the insights come from

---

In this section:

- Webhooks: Send Cogny Events to Slack, Zapier or Your Own Server: https://cogny.com/docs/webhooks
- **How Growth Tickets Work** (this page): https://cogny.com/docs/growth-tickets-architecture
- How AI Reports Work: https://cogny.com/docs/ai-report-generation-how-it-works
- How ICP Analysis Works: https://cogny.com/docs/icp-analysis-technical-overview

Source page: https://cogny.com/docs/growth-tickets-architecture  
All documentation: https://cogny.com/docs  
Cogny for agents: https://cogny.com/llms.txt
