← Jetformat blog

Local automation

A safer pattern for local PDF workflows

A useful file workflow is easy to inspect: the input path is known, the command is repeatable, and the output is visible to both the user and the agent.

Published September 12, 2026

AI automation becomes easier to trust when it leaves a small, readable trail. For document work, that trail should include the source file, the command that ran, the output path, and the validation step.

Keep the source where it already lives

Uploading a contract or board deck to a temporary conversion service adds a new data boundary. A local CLI avoids that detour. Jetformat accepts a path and writes the result beside it, so the user can inspect the files with the tools they already use.

Separate conversion from inspection

Conversion answers “can this file become a PDF?” Inspection answers “what did we get?” Keeping those steps separate makes failures easier to diagnose and lets an agent show a preview only when the user asks for one.

jetformat convert report.docx -o report.pdf
jetformat pdf info report.pdf --json
jetformat pdf render report.pdf --pages 1 --width 1600

Report facts, not confidence

The agent should say that Jetformat wrote report.pdf and include the page count returned by pdf info. It should not claim a file exists because a command was suggested, and it should not fabricate a preview or page count.

Make the happy path short

Teams adopt automation when the first successful run is straightforward. Start with one document, keep output names explicit, and use the same command in the GPT Skill, DeepSeek Harness, and a terminal session.

Read the complete CLI reference →