> For the complete documentation index, see [llms.txt](https://omalab.gitbook.io/guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://omalab.gitbook.io/guide/engineering-wiki/processors-automation-pipeline/agents.md).

# Agents

Agents are the main component of the Automation Pipeline. They are the tool that receives events (in most cases) and processes them, emitting events.

The general Agent has the following configuration information:

* description (required) = a description that will be shown on the front end
* schedule (required) = how often that agent should run
* keep\_events\_for (required) = how long before we delete its events
* criteria (agent-dependent) = the criteria that is configured by the end user.
* group\_criteria (agent-dependent) = whether the agent subscribes to only certain events.

Agents have a "process" method that, in all cases, performs all of their processing. It is expected that, unless necessary, they will have an "process\_event" as well. This will process each event. It is expected that the event's payload will be passed on downstream as well (unless the proces\_event returns a false).

Agents, unless customized, use a "search\_query" that will find their events to process. This query is run, and a list of "results" is produced. They are fed into a loop that runs the process\_event on each of them.

Given all this "commonality", a child agent will have often just a "process\_event" implemented. the rest can be inherited by the basic system.

**Segment-based Agents**

For segment-based agents (InfluencerSegment), they also take a "segment\_id" as part of their configuration. They do not receive events. They only produce them. By default, they emit a new event every time a new object (Influencer, Mention, Backlink, Page) matches their segment criteria.

**Conditional/Grooming Agents**

There a a number of agents that are built to split events, limit the reate of events, filter events, etc. These are built as agents as well.

**Update and Edit Information Agents**

Currently there are Update Field (updates an object's field) and AddField (updates an event with data that is passed downstream). These are so we can update information. There is also a "Add to Negatives List" that will add an Influencer to the project's negatives list. This should have the consequence that it will take it out of processing across all project pipelines.

**Service-based Agents**

Based on our Service models (Twitter, Facebook GooglePlus, etc.) we can take actions with an object based on usage of this service (follow, unfollow, send messages, etc.). These use our existing message templates.

## Connections

Agents are connected using a "connection". Both agents have to be saved first (so they have ids). These connections are what the agent uses to determine what events to listen for.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://omalab.gitbook.io/guide/engineering-wiki/processors-automation-pipeline/agents.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
