Tickets and Approvals
How the ticket board works, the three decisions on every ticket, why the first twenty deserve real review, how feedback teaches the agent, and how to turn on auto-execution safely.
Tickets are the experiment backlog. Reports produce insights; a second agent reads them each week, prioritises by expected impact, and writes each proposal up as a ticket with everything needed to execute it. Your job is one weekly pass over the New column. Getting a team to a prioritised, executable backlog used to take an agency months; here it is the state of the board on day two.
Where
Top navigation → Tickets. Columns: New, Assigned, In Progress, Review, Analysis, Done, Rejected. The header has three actions:
- Generate Tickets: create a new batch from recent reports now.
- Create Ticket: write your own. Describe the goal ("new ICP: solo founders in the UK; landing page, a Google Ads campaign and three articles") and the agent refines it into one or more tickets you approve.
- Review Meeting: record a meeting; the discussion is saved to context and every action item becomes a ticket.
Scheduled ticket generation (a daily pass after reports) is turned on for your workspace by the Cogny team during onboarding.
What a ticket contains
A brief: the source reports, the integration and tools it will use, and the full specification. For a paid campaign that means account, campaign settings, ad groups with keywords and negatives, destination URL, headlines and descriptions. For a page it means URL, headline, sections, social proof and design notes. You do not need to be a specialist to judge whether the keywords and headlines make sense.
Each ticket has one execution target:
| Target | Who executes | What you see |
|---|---|---|
| Agent | The agent, through the integration's tools | Approve, Refine, Reject |
| Code | The coding agent, as a pull request | Run Code Agent, Refine, Reject |
| Manual | A person on your team | Assign, then record the outcome |
The three decisions
- Approve executes it. Integration tickets run immediately. Code tickets open a pull request with a preview. Manual tickets go to the assignee.
- Refine sends your notes back ("shorter headlines", "exclude the outlet category", "target the German site"). The agent rewrites the brief and returns it to New.
- Reject with a reason. The reason is the important part. "Never recommend Snapchat again", "we already did this in March", "wrong audience, we are B2B" all teach the agent, and the next generation checks past rejections before proposing anything similar.
Anything you want followed up as an experiment should be a ticket. If you just want to change a budget or pause an ad, use chat; it can do everything tickets can, without the follow-up.
The first twenty tickets
Review the first twenty properly, with the person who owns the channel. This is the calibration period. Expect a few tickets that repeat something you did, ignore a constraint you had not written down, or misread a metric. Each one you refine or reject with a reason fixes a class of mistake. After twenty, the board reflects what you would have decided, and you can consider automation.
Beyond approve and reject, every ticket takes structured feedback: useful, already done, not actionable, incorrect data, duplicate, out of scope. Feedback is appended, never overwritten, and both ticket generation and the approval scorer read it.
The lifecycle after approval
- In Progress while it executes.
- Review for code tickets: the pull request is open, a preview deployment renders it, and a visual proof review compares the page to the brief. You merge from the ticket or in GitHub. Merging moves the ticket on automatically.
- Analysis: the ticket waits for data, then the agent evaluates the outcome against the expected result. If data is thin, it reschedules itself. Paid campaign tickets go here straight after launch.
- Done with an evaluation: success, partial, failed or inconclusive, plus what worked and what to change. These learnings feed the next round of reports and tickets.
For changes your team makes by hand, use Assign to yourself, comment the implementation date and what was done, set the expected outcome, and move it to Analysis so the agent evaluates it like any other experiment.
Approval scores and YOLO mode
Every ticket gets an approval likelihood score from 0 to 100, based on your approve and reject history and on the quality of the ticket itself. It is shown on the card.
YOLO Mode (Settings → Automation → YOLO Mode) auto-approves tickets above a confidence threshold. The slider runs from 50 to 100 in steps of five; the default is 85. Below 60 is aggressive, 60 to 75 moderate, 75 to 90 balanced, 90 and above conservative. The settings page recommends reviewing 10 to 20 tickets manually before enabling it.
Two guardrails apply regardless of the threshold:
- A ticket can only auto-execute if every tool it uses is read-only or explicitly granted for that job. Budget changes, campaign edits and audience mutations always require approval unless you have granted that specific write tool.
- Code tickets never auto-merge. A pull request always needs a human.
One SaaS customer runs YOLO against a CMS so content changes go live unattended. Most teams keep it off for the first month and turn it on for content and low-risk actions once the board has been calibrated.
Practical rules
- Keep the New column short. A board with 40 unreviewed tickets is a sign the reports are producing more than the team can act on: disable a report or raise the bar.
- Ten tickets can run in parallel. Approving in batches on the weekly pass is fine.
- Ask "would I have done this without Cogny?" A ticket that only confirms what you already planned is still worth approving, because the analysis step measures it.
- A rejected ticket that keeps coming back means the reason was not specific enough, or the rule belongs in the growth strategy.
- Coding and content tickets consume the most credits; a campaign ticket is cheap. See credits.
Reading this with an AI agent? Fetch the raw markdown at /docs/tickets-and-approvals/index.md or see llms.txt.