Define the data proactive intake agent

Most people meet AI as a chat assistant. You type a request, it answers, and then it waits. Nothing happens until you ask again.

A proactive agent works the other way round. It acts on an agreed schedule (every weekday at 7:00) or a trigger (a new sample file lands in the intake folder). Nobody prompts it each time.

Here is an example. Your team receives regional sales files during the first days of each month. With a chat assistant, someone has to notice each file, upload it and ask for a check. A proactive intake agent notices the file itself, checks it against agreed rules and prepares the result for review.

That independence is useful, and it brings a duty. You are not in the room when the agent acts, so you cannot correct it mid-task. Its limits have to be written down before it runs: what it may read, what it may produce, who checks the work and how to stop it. That written statement is the agent brief, and writing one is the main task of this lesson.

An agent brief is the written instruction that defines what a proactive agent may do. For an intake agent, it covers seven parts:

1. Role name: a short, recognisable name, such as Intake Watch.
2. Task: one sentence. "Check arriving sample sales files against the acceptance rules and load accepted rows into the March dataset."
3. Inputs it may read: for example, only the folder /sample/intake/march/.
4. Approved connections: the systems and tools your organisation has authorised the agent to use, such as the course's sample folder and nothing else.
5. Outputs it prepares: the consolidated dataset and an intake log.
6. Reviewer: a named person, for example the financial controller, who checks the outputs before anyone relies on them.
7. Pause or retire steps: how a person stops it temporarily, and how they end it for good. One example: "Rename the trigger folder to pause. Retire by archiving the brief and recording the date and reason."

If you cannot fill in one of these parts, the agent is not ready to run.

Without a fixed destination, arriving files turn into an unexplained collection of spreadsheets: sales_v2_final.xlsx, sales_v2_final_JB.xlsx, and so on. The intake agent should load everything into one target dataset, a single table with fixed columns.

Here is a workable layout:

Column	Example
reporting_period	2024-03
entity	North
account	4000 Revenue
amount	240.0
currency	EUR
units	thousands
source_file	sales_north.csv
batch_id	B001
load_date	2024-04-03
status	accepted

Period, currency and units sit on every row, not just in a header or a file name. A figure of 240 means something very different in units than in thousands.

The source file name and batch ID make every row traceable. When a reviewer asks where North's revenue came from, the answer is in the row itself.

Acceptance rules are the agreed tests a file must pass before any of its rows enter the dataset. A typical intake agent checks four things:

• Period: the file is for the period being prepared. A February file in the March batch is rejected.
• Columns: every required column is present. A file missing the currency column is rejected.
• Currency and units: they match what was agreed. A file in USD, or in units when thousands were expected, is rejected.
• Control total: the sum of the file's amounts agrees to its control total, the total the sender states separately, for example in a cover note or a summary row.

A rejected file is logged with its reason and never enters totals. The agent does not fix the file, guess a currency or force the numbers to agree. The reviewer decides what happens next, which is usually asking the sender for a corrected file.

This matters because a rejected file that quietly enters totals is one of the hardest errors to find later. The pack still looks finished, but its numbers are wrong.

Files often arrive twice. A sender re-sends with "in case you missed it", or someone drops the same file into the folder a second time. If the agent loads both copies, the period is double-counted.

A duplicate key prevents this. It is a combination of columns that should be unique in the dataset. For the intake agent, a sensible key is:

reporting_period + entity + account + source_file

Before loading a row, the agent checks whether that key already exists. If it does, the row is not loaded, and the duplicate is recorded in the intake log for the reviewer.

For example, North's revenue for March is 240 thousand from sales_north.csv. If that file is loaded twice without a key check, North's revenue reads 480 thousand. The total looks plausible and is wrong by exactly the amount of the duplicate.

Use the explorer to see how quickly a repeated load inflates a period.

This course uses sample data only. Your intake agent has no connections to a live ledger, ERP system or bank feed. Customer identifiers, account credentials and nonpublic reporting data must not go into any cloud tool your organisation has not approved. Put this in the brief's approved connections, for example: "Sample folder only. No other systems."

Every run writes an intake log for the reviewer. It records the files received, accepted and rejected, the reason for each rejection, row counts and control totals.

Here is an example from the March batch, in EUR thousands:

• sales_north.csv: 412.5 against a control total of 412.5. Accepted, 38 rows.
• sales_south.csv: 298.0 against 298.0. Accepted, 31 rows.
• costs_central.csv: 187.2 against 181.7. Rejected for a control total difference of 5.5.

The reviewer can see from the log alone that 3 files arrived, 2 were accepted and 1 is waiting for a corrected version. Without the log, they would have to reopen every file to find this out.

The last decision in your brief is how often the agent works.

• A single run processes one batch and stops. You read the dataset and the intake log, compare them with the source files and judge the result.
• A continuing brief has the agent revisit the inputs at agreed intervals, for example every morning during the first week of the month, and process whatever has arrived.

For the first version, start with a single run. You do not yet know whether your acceptance rules catch everything. You also do not know whether the duplicate key is right for your data, or whether the log tells the reviewer what they need. A single run lets you find out on one batch, with nothing compounding.

Move to a continuing brief only once the outputs have been checked and trusted. When you make the change, update the brief: add the interval, confirm the reviewer and keep the pause and retire steps. In the next lesson you will put this to work by processing a second reporting batch.

Your task now is to draft the full brief for Intake Watch with your tutor, choosing a single run.