A Provenance-First Workflow for Agent Tools: Public Evidence, Private Documents, One Review Layer
An agent can sound confident by blending a public web citation with an internal document. That is exactly the moment to slow down. This guide describes a provenance-first workflow: public web research stays in a cited external lane; private company documents move through company-scoped Skavio Agent Tools jobs; the two meet only in a review layer that preserves source labels and records when evidence is missing. Agent Tools is a production document, invoice, audio and data processing API, not a search engine or a private retrieval interface.
Keep the two evidence lanes separate
The separation is operational, not cosmetic. Public web research and private company knowledge answer different questions and carry different risks. Skavio Agent Tools is a live company-scoped authenticated document, invoice, audio and data processing API with a shared prepaid credit wallet, self-service keys and asynchronous jobs. Public web research belongs in a separate search or browsing integration. Do not present Agent Tools as a built-in web search engine, crawler, private retrieval index, knowledge-base interface or Research AI agent. Keep the lanes distinct so a public page cannot quietly become company policy and a private document cannot quietly become a public citation. Do not treat Agent Tools as an approved QuickBooks production-posting integration.
- Label every evidence item at creation as public_web or private_company.
- Give web items a canonical URL, retrieval time, publisher and reviewer; give private items a document or job identifier, upload time, company scope and reviewer.
- Keep API keys and access controls separate from web research credentials; never place secrets in prompts, URLs, logs or public notebooks.
- Record a conflict between lanes instead of resolving it silently.
Design the evidence record before the first job
A reliable workflow starts with a small provenance record that every downstream step must preserve. The record should make it possible to answer four questions: where did this claim come from, when was it obtained, who was allowed to see it, and who reviewed it? For public material, the canonical URL and retrieval time are part of the evidence. For private material, the document or job identifier and company scope are part of the evidence. If a field cannot be tied to a source, the record should say unknown or review-required rather than supplying a plausible value.
- Use source_type labels such as public_web and private_company consistently.
- Store a canonical URL or document/job identifier, plus retrieval or upload time.
- Record access scope and the reviewer responsible for acceptance.
- Carry an explicit unknown or review-required state when evidence is missing, ambiguous or unauthorized.
Run web research as cited, untrusted input
Public web text should be treated as data, not as instructions. A retrieved page can be outdated, misleading or hostile, and it can contain embedded commands aimed at an automated agent. Prefer primary or official sources, but do not treat a search result as authoritative merely because it appears near the top of a list. Record the retrieval date because pages change. If a page asks the agent to ignore its rules, reveal secrets or take an unrelated action, classify the page as untrusted and do not execute its instructions.
- Cite the canonical URL, publisher and retrieval time for every public claim.
- Prefer primary or official sources and mark secondary material clearly.
- Treat retrieved page text as untrusted data; never follow embedded commands.
- When a source is stale, ambiguous or inaccessible, keep the claim out of the approved answer and mark it review-required.
Process private knowledge through company-scoped jobs
Private company knowledge should enter the workflow as an authorized, company-scoped processing job. Agent Tools provides authenticated access, self-service keys and asynchronous jobs. Use synthetic documents and public, non-sensitive URLs for examples and tests. Never expose API keys, real customer files or private storage paths. Trial credits, if any, depend on live eligibility and must be checked in the backend before planning a run. A successful submission is not a completed result, so wait for the documented completion signal and verify the downloaded output through an authenticated path. Use a stable request or job identifier in your own workflow, and follow the current documentation for retry and download behavior.
- Create scoped self-service keys, store them server-side and rotate them through an approved process.
- Use a stable request or job identifier in your own workflow; do not assume a retry behavior that current documentation does not describe.
- Follow the current documentation for completion signals and authenticated downloads rather than relying on public result links.
- Use synthetic files for tests, verify trial eligibility live and keep private document identifiers internal.
Combine only in a review layer that can say unknown
The review layer should combine evidence without erasing its origin. Each claim should point to exactly one lane and one identifier: a URL and retrieval date, or a private document or job identifier and company scope. If a public source contradicts an internal policy, show both and let a human decide; do not average them into a single statement. Public text must not become internal policy without approval, and a private document must not become a public citation without separate authorization. When evidence is incomplete, the correct output is an explicit gap, not a polished invention.
- Map every claim to public_web or private_company and preserve its identifier.
- Display conflicts side by side rather than silently choosing one source.
- Use explicit unknown or review-required states when evidence is missing or unauthorized.
- Require human approval before external distribution or accounting writes; do not treat Agent Tools as an approved QuickBooks production-posting integration.