Tremau Agents

trust & safety teams make hundreds of moderation decisions a day, and a significant share of them follow clear, repeatable patterns that don't require a human judgment call routing those cases through review queues anyway burns moderator attention on outcomes that were never in question, accelerates fatigue, and slows response on the cases that genuinely need human review tremau agents let you define those repeatable enforcement patterns once and execute them at scale, keeping predictable cases out of queues entirely overview tremau agents are pre built pipelines for common enforcement scenarios — ready to clone and configure without starting from scratch tremau agents are separate from the rule engine the rule engine governs how incoming content is routed at intake in nima agents act on cases already in queues within nima in new status , and run on demand or on a schedule you define when to use an agent use one when the enforcement decision for a category of cases is clear and consistent — and the cost of routing through a review queue isn't justified common scenarios clearing aged backlogs, auto enforcing high confidence detections, and enforcing policy on recidivist accounts how it works an agent is a pipeline with steps that run in the order you define each step either narrows, enriches, or acts on the active case set before passing control to the next step cases are processed in batches of 20 through the pipeline the basic pattern fetches matching cases, loads their context, optionally filters, and enforces fetch reports → pull cases → filter (optional) → apply policy select cases load full narrow the set & by criteria context trigger action enforcement follows the same execution path as a manual moderator decision — the action configured for the policy fires, the webhook posts to your platform, and the case status updates in nima all decisions are logged in the audit trail, with the agent identified as the actor step types agents are composed of typed steps each step has a defined role in the pipeline and determines what criteria it accepts fetch reports — fetch reports selects cases from nima in new status that match the criteria you define always the first step results are grouped by content id , so multiple reports on the same content are treated as a single case criteria content type , queue , reporter , reportee , custom attributes , event logs pull cases and load context — client config loads full case details and context from nima into the agent for the case set produced by fetch reports does not filter or modify the case set always follows fetch reports accepts no criteria filter — check if evaluates the active case set against additional conditions and retains only cases that match cases that do not match are dropped — they remain in new status in nima and are not moved to any queue criteria content type , channel , queue , reporter , reportee , custom attributes , event logs apply policy — policy agent enforces a specified policy and decision on every case in the current set the action configured for that policy fires automatically requires a policy and a decision — both must exist in your nima configuration criteria policy id , decision id log — logger (coming soon) records execution details to the audit log for the cases processed in that run useful for traceability when a pipeline does not apply policy — for example, to document that a case set was reviewed and found compliant templates templates are pre built pipelines for common enforcement scenarios each template is a starting point — once you clone it, you can adjust the criteria or change the policy before activating recidivist account enforcement (account safety) fetches cases from accounts with confirmed prior violations and applies a stricter policy decision without standard queue routing the filter acts on existing account history data already present in nima fetch › pull › filter (prior violations > 0) › apply policy trusted flagger fast track (compliance) filters for submissions from designated trusted flaggers and routes them directly to enforcement, supporting the dsa obligation for expedited handling of trusted flagger notices scoped to the trusted flagger source only — user reports are unaffected fetch › pull › filter (channel = trusted flagger) › apply policy text spam backlog clearance (efficiency) clears accumulated text spam cases raised through proactive detection the source filter ensures only proactive detection cases are processed — user reported spam remains in queue for human review fetch (text) › pull › filter (channel = automated detection) › apply policy criteria reference criteria follow an attribute / operator / value pattern, consistent with the rule engine each criterion is evaluated independently — a step applies only to cases satisfying all defined criteria attribute group examples applies to steps content type img, video, text, audio fetch reports, filter queue queue id or name fetch reports, filter channel user report, automated detection, trusted flagger, lea filter reporter reporting account metadata fetch reports, filter reportee reported account metadata and history fetch reports, filter custom attributes any custom field configured on your instance fetch reports, filter event logs case history fields fetch reports, filter policy id policy numeric id apply policy decision id decision numeric id apply policy supported operators == != > >= < <= contains use contains to match against a list of values — for example, matching multiple content types in a single criterion the channel attribute is the source of the case its values are used verbatim as shown above key considerations agents trigger enforcement actions cases processed by an agent bypass the moderation queue entirely the configured action fires automatically and posts to your platform via webhook verify your policy and decision configuration before running against a large case set new cases only agents operate exclusively on cases in new status cases already under review, processed, or closed are not affected, regardless of whether they match your criteria cases dropped by a filter step are not modified dropping a case means it does not continue to apply policy it remains in new status and can be picked up by a future run or reviewed manually batch processing cases are processed in batches of 20 large case sets run to completion — batching is transparent and does not affect which cases are processed all decisions are audited every enforcement action applied by an agent is recorded in the audit log, with the agent identified as the actor the full trail — criteria, matched cases, applied policy, and action outcome — is preserved policy and decision ids must exist in your instance the apply policy step requires valid identifiers for both if either does not exist in your configuration, the step will not execute for that batch related rule configuration docid\ hfx29ae9o5ktdj2 dokxb — setting up detection and routing rules policy configuration docid\ r6vgf6m3d k8slkyopppp — defining policies and decisions actions docid\ lsfkyoqsi365x alowit1 — configuring the enforcement actions agents trigger