How to let an AI agent file documents in your document management system

Grant filing one action at a time. The agent reads the repository, classifies each document, sets metadata and places it in an approved location at depth 3. Retention classes outside the routine set, legal holds, permission changes and anything that deletes or supersedes a record stay with the records manager, and every filing is recorded with its reasons.

What does filing involve, and who owns it?

Filing looks like one action, but in a document management system it is several. The agent must decide what the document is, which customer, matter or case it belongs to, which folder or cabinet it goes in, what metadata it carries, which retention class applies, and whether it is a new document or a new version of an existing one. Each of those decisions has a different cost when it is wrong.

The records manager owns the file plan, the retention schedule and the permission model. Team leads own the documents in their area. The agent owns nothing; it applies the file plan on their behalf. That distinction matters because a misfiled document is not just untidy. It can be invisible to the person who needs it, visible to someone who should not see it, or deleted on the wrong schedule.

Which permissions should the agent get, and at what depth?

Before any of this, the agent needs a working connection. The setup of service accounts, scopes and test repositories is covered in connecting an AI agent to your document management system. This playbook assumes that is done and asks the harder question: which actions does the agent get, and how far may it go with each?

1. Agent, depth 1: reads the incoming document and the file plan. It extracts the document type, parties, reference numbers and dates, and looks up the matching customer or case record.
2. Agent, depth 1: checks for an existing document. If the same reference or a near-identical file already exists, it treats the new one as a possible version, not a new record.
3. Agent, depth 2: proposes the classification and location when its confidence is below the floor set at certification, or when the document type is not on the routine list. A person confirms or corrects.
4. Agent, depth 3: files routine documents. Creates the document in the approved location, sets the metadata fields the file plan defines, and links it to the customer or case record.
5. Agent, depth 3: applies routine retention classes. Only the classes listed for that document type.
6. Agent, depth 2: proposes a new version. Checking a document in as a version of an existing record changes what others see, so a person confirms.
7. Person, records manager: decides non-routine retention, legal holds and declarations of a final record.
8. Refused for the agent: changing permissions, sharing outside the team, moving documents it did not file, and deleting anything.

The distinction between steps 4 and 8 is where most deployments go wrong. Creating a document in a location the agent has write access to is routine. Moving someone else's document changes their work, and changing permissions changes who can see it. Those are different capabilities and should be certified, or refused, separately.

What is recorded for each filing?

Every filing should leave enough to answer three questions later: what did the agent see, what did it decide, and on what basis.

The source. Where the document came from and its provenance: an email attachment is external; a document generated by the core system is sealed. The class decides how far the agent may trust what the document says about itself.

The decision. Document type, location, metadata values, retention class and the confidence for each. If a person corrected the proposal, the correction and their name.

The verdict. Allowed, held or refused, and which bound decided it. If the agent tried to file into a cabinet outside its role scope, the record shows the refusal and the bound that refused it.

A content fingerprint. A hash of the file at the moment of filing, so you can prove later that the stored document is the one the agent filed.

Our guide on how to document an AI agent's process covers how these records fit into the wider process documentation that auditors expect.

What should you measure?

• Corrections at depth 2, by document type. A type that is corrected often is not ready for depth 3.
• Misfiles found after filing, by how they were found: a person searching, a periodic sample, or a complaint. The last is the most expensive.
• Duplicates created, which shows whether the version check is working.
• Time from arrival to filed, for routine and held documents separately.
• Refusals, by bound. Repeated refusals on the same cabinet usually mean the file plan or the role scope needs revisiting, not the agent.

Where does it usually go wrong?

The file plan lives in people's heads. If the rules for where a document goes are not written down, the agent will learn the inconsistencies of whoever reviewed its training cases. Write the plan first. The broader deployment sequence in train, shadow, certify, widen assumes the job is defined before the agent is trained on it.

Filing is confused with indexing. Indexing makes documents findable in a store the agent searches; filing places the record of truth. The work in indexing documents into the document store is lower risk and can run deeper sooner. Keep the two capabilities separate.

Extraction is trusted too far. Classification depends on reading the document correctly. Intelligent document processing gets the fields out; it does not tell you whether the document is what it claims to be. A letter that says it is from a regulator is external until something stronger confirms it.

Write access is broader than the role. Service accounts are often given write access to a whole repository for convenience. The agent's bounds then rely on its own judgement. Narrow the account to the cabinets in scope, so the system refuses what the agent should not do even if the agent tries.

Versions overwrite records. An agent that checks in a new version of a signed contract can hide the signed one from view. Version decisions stay at depth 2 until certification shows the agent reliably tells a new document from a revision.

Where Pryme fits

In Pryme, filing and versioning are separate capabilities, each certified by Attest on your own past documents. Every filing passes the minimum chain, and the verdict names the bound that decided it. Permission changes and deletion sit outside the agent's role scope, so attempts are refused and recorded rather than relying on the agent to decline.