Inspect an Attachment
Returns one uploaded document's stored details together with a preview of the text already inside the file, so the agent has something beyond the filename to go on — available in the appraisal and pre-bid workflows.
Overview
The inventory of a package tells the agent that it holds a long PDF that looks like a prior submission and a short one that might be a cover letter. It does not tell it whether the long file is last year's approved bid or a vendor's catalogue somebody dropped in by mistake: the inventory carries no text from inside any file.
This is the closer look at one of them. It returns the same details the inventory holds for that document, plus the one thing the inventory does not have — a preview of the text.
The preview is not read at that moment. It was taken once, when the file was uploaded, and how much of the document it covers was settled then, by the role the file was given on arrival:
- A file that arrived as a prior completed package The opening of every page — the first 200 characters of each of the first four pages, then the first 100 characters of every page after that.
- A file that arrived as an invitation to bid The first 200 and the last 200 characters of every page, joined; or the whole page, when the page holds 400 characters or fewer. The closing characters are there because signatures and dates sit at the foot of a page.
- Everything else The first 800 characters of each of the first two pages, and no more than 2,000 characters in total. Page three onward is not in it.
Whichever shape it takes, the preview contains only text the file already carried. There is no recognition step, so a page that is a picture of a document contributes nothing to it.
What It Does
| Capability | What it means for you |
|---|---|
| One document at a time | Everything recorded about a single attachment, in one response |
| Text preview | A sample of the words the file already carries, so the agent has more to work from than a name |
| Every page represented, for two kinds of file | A prior completed package and an invitation to bid are sampled page by page, not just at the front |
| Length and form fields | How many pages were recorded for the document, and whether it carries interactive form fields |
| Read-only | The file itself is never opened — what comes back is what was stored when it was uploaded |
When the Agent Chooses This Tool
Two of the three workflows can call this: appraisal packages and pre-bid packages. The coating QA workflow cannot.
Neither of the two leaves the choice open. Each names the one file worth inspecting and what to read out of it:
- An appraisal package that includes a prior completed deliverable. Before that file can be split into per-section sources, every one of its pages has to be matched to a part of the package being built. The page-by-page preview is what the agent maps from, and the subject address it is required to record comes out of the same text. When no such file was uploaded, the step is skipped and the tool is not called.
- A pre-bid package, once, on the invitation to bid. The contractor signed and dated the file before sending it, and the deliverable has to carry today's date instead. The agent reads the preview to find the old date — which is why every page's closing characters are in it — and then replaces that text. If no date turns up in the preview, the replacement is skipped rather than guessed at.
Nothing else in either workflow asks for it. Page counts are already in the inventory, so the appraisal workflow is told not to inspect a file merely to size it. And which sources feed which form is not something the agent works out by looking — both workflows are handed that mapping, and the appraisal workflow is told on top of that not to pass every attachment to every section.
Inputs and Outputs
Takes: the identifier of one document attached to the package being worked on. A document belonging to another package is refused.
Returns: the document's filename, file type and size; the number of pages recorded for it; whether it carries interactive form fields; the role it was given when it was uploaded; and the text preview.
Nothing is changed. The document is not modified, converted, filled or moved — it is not even downloaded.
Example
A contractor uploads an HPD invitation to bid: a PDF they filled in and signed some weeks ago. The deliverable has to go out dated today, so the old signature date has to be found and swapped.
The agent inspects the file. Because it arrived as an invitation to bid, its preview carries the first and last 200 characters of every page — and a signature date is exactly the kind of value that sits at the foot of an inner page, inside those closing characters. The agent reads the date out of the preview, collects the format variants it appears in, and calls for the replacement with today's date.
Had the date not appeared in the preview, the workflow would have skipped the replacement instead of inventing one.
Limits
- The preview is a sample, not the document. For anything other than a prior completed package or an invitation to bid it stops at the second page and at 2,000 characters, so a value on page three is not in it.
- A page-by-page preview is still only the edges of each page. Every page is represented, but by its opening — and, for an invitation to bid, its closing. A value in the middle of a page is not there.
- Only text the file already carries. There is no recognition step, so a scan that was never made searchable comes back empty however clean the scan is. That does not stop the document being used to fill a form: filling sections reads rendered pages rather than the stored preview.
- Uploads that are not PDFs have no preview and no page count. A spreadsheet, a photograph or a text file comes back with its name, type and size, the role worked out from its filename, and a report that it carries no interactive form fields.
- It is a snapshot, not a live read. The preview was taken at upload. Tools that edit an attachment during a run refresh it, so an inspection after such an edit shows the edited text.
- One document per call. Getting the shape of the whole pile is what listing attachments is for.
- Inspecting is not filling. Seeing a value in the preview does not put it in a form.
FAQ
Does the agent read every uploaded document in full?
No — nothing is read in full. Most documents get a preview of their first two pages, capped at 2,000 characters. Two kinds of file are sampled across every page instead: a prior completed package, and an invitation to bid. Even those carry only the first couple of hundred characters of each page.
Why not just trust the filename?
The role in the response is the filename's verdict — it is worked out from the file's name when the file is uploaded, and it also settles how much of the document the preview covers. The preview is the part that does not come from the filename, and that is the reason to ask for it: a file called "final report" that is really a blank template reads as a blank template.
Can it read scanned documents?
Only where the scan already carries a text layer — the kind you could select and copy in a PDF reader. There is no recognition step here, so a scan that was never made searchable returns an empty preview, and a clean scan is no better off than a poor one. A document with an empty preview can still be used to fill a form; that path reads rendered pages rather than stored text.
Does inspecting a document change it in any way?
No. It is a read of a stored record. The file is not downloaded, let alone converted, filled, re-ordered or moved.
How is this different from extracting a document's text?
Inspection hands the agent a short sample so it can tell what one attachment is. Pulling the full text out of a document is not something the agent calls at all — it happens inside the pipeline that fills a section, page by page, from rendered pages.