Insert Source Pages into the Deliverable
Names pages of an uploaded PDF and the position they belong at; the pages go into the package when it is assembled at the end of the run.
Overview
Not everything in a deliverable is a form the agent fills. Some of it is a document that already exists in final form, and the only correct thing to do with it is put it into the package as it is. It still has to land in the right place: reviewers and submission portals expect a sequence, and a package with the right pages in the wrong order comes back.
This tool records that placement rather than carrying it out. A call names an uploaded PDF, which of its pages to take, and the position they belong at, counted from the first page of the assembled package. Nothing changes at that moment. The pages are put in later, when the package is assembled at the end of the run — after the filled sections have been merged in the package's own order.
What goes in is what was uploaded. The pages are copied as pages, not re-rendered or re-typed: text stays text, a scan keeps the quality it arrived at, and a signature stays where it was signed. Interactive form fields are the one exception, and they are covered in Limits.
What It Does
| Capability | What it means for you |
|---|---|
| Named pages | Specific pages of an uploaded PDF, not the whole file |
| Counted from page 1 | The position is measured from the first page of the assembled package, never from a section boundary |
| Copied, not re-rendered | Text stays text; nothing is rasterized, resized or down-sampled on the way in |
| Sources from the same package | The pages come from a PDF uploaded to the package being built |
| Applied at assembly | The call records the request; the pages go in when the package is put together, after the merge |
When the Agent Chooses This Tool
One workflow can call this: contractor pre-bid packages. Appraisal and coating QA packages have no insertion step at all — a tool a workflow does not register is a tool its agent cannot call.
Inside that workflow it is barely a choice. The instructions name the document — the invitation to bid the run started from — and derive the pages arithmetically rather than by judgement: everything except the first two pages, which are placed as images on the package's own form, and the last page, which the template already contains. What is left is the middle of the document, and it goes in ahead of the template's third page. That position is fixed by the workflow. The step is skipped when there is no middle to insert, it runs only on the run that uploaded the file, and it is called at most once.
The ordering is fixed too, and none of it is the agent's to arrange. Sections are merged first, in the package's own order. The recorded insertions are then applied to the merged result. Headers and page numbers, where a package gets them, come after that — see Stamp Headers and Page Numbers.
Inputs and Outputs
Takes: the uploaded document to take pages from, which of its pages, and the position in the assembled package where they go, counted from page 1. The package itself is not named in the call — it is the one the run is working on.
Returns: a record of what was noted down — the document, the pages, the position, and how many insertions are now recorded for the package. No document comes back. The pages appear when the package is assembled.
Example
A contractor pre-bid package is built from a single upload: the invitation to bid. Its first two pages are placed as images on the package's own form, and its last page already exists in the template, so those three are spoken for. The pages in between — the continuation of the job description and the supporting content behind it — have nowhere else to go.
The agent makes one call: this document, that range of pages, position three. Nothing changes in any file at that point; the request is written down against the package.
When the run ends, the package is assembled. The sections are merged in order, the recorded insertion is applied to the merged file, and the middle pages of the invitation land ahead of the template's third page, still the pages that were uploaded. Had the upload had no middle pages, the step would not have happened at all.
Limits
- The call records an insertion; it does not perform one. The pages go in when the package is assembled, and there is nothing to look at before then.
- A position holds one insertion. Recording a second one at the same position replaces the first, and the call still reports success — the first document's pages are simply absent from the deliverable.
- Positions do not shift each other. Every recorded position is measured against the assembled document as it stands before any insertion is applied, so they never need adjusting for one another — and adjusting them puts the pages in the wrong place.
- A recorded position is re-applied unchanged every time the package is assembled. If the package is later assembled from a different set of sections, that same number lands somewhere else.
- The pages arrive as they are. Nothing on them is filled, straightened or cleaned up; if the scan is crooked, the deliverable contains a crooked page.
- Interactive form fields do not survive. A page that had fillable fields arrives without them, and a value that was showing in a field is not in the deliverable.
- The source has to be a PDF already uploaded to the same package. There is no fetching from anywhere else mid-run.
FAQ
Can I include a signed letter or permit in the finished package?
Only through the one workflow that has an insertion step, contractor pre-bid — and there the instructions already name the document and the pages: the middle pages of the invitation to bid the run started from. This is not a general "attach this document" step an agent picks per upload.
Can I insert just a few pages from a long document?
Yes. The call names the pages, so a range out of the middle of a long PDF is exactly what it takes. The rest of the document stays out of the deliverable.
Where exactly do the pages end up?
At the recorded position, counted from page 1 of the assembled package. Positions are all measured against the assembled document before any insertion is applied, so several insertions do not push each other along, and none of them needs adjusting for the others.
Is this different from merging?
Yes. Merging combines the package's sections in their own order. Insertion is a separate pass over the merged result at an absolute position, which is why it happens after the merge rather than as part of it.
Are the inserted pages modified in any way?
They are copied as pages rather than re-rendered or re-typed, so text stays text and a scan keeps its quality. Two things do change: the file is rewritten and recompressed when the assembled package is saved, and interactive form fields do not come across.
What if the page numbers stop matching after an insertion?
They cannot. Headers and page numbers, where a package gets them, are applied after the insertions have gone in. The order is part of assembly, not something anyone sequences.