Building AI-Native CLIs for Construction Software

When we started building AI agents for construction operations, we hit a problem that had nothing to do with AI.

The problem was plumbing. Our agents needed to read project data from Procore, order measurements from EagleView, and push updates across multiple systems. The APIs existed. The documentation existed (mostly). But there was no clean, scriptable way to access these platforms that an AI agent could use reliably.

So we built our own CLIs — and designed them from day one for a consumer that isn’t human.

The Design Constraint: No Humans in the Loop

Traditional CLIs are designed for humans. They have interactive prompts, colorful output, progress bars, confirmation dialogs. All of that is useless — worse, actively harmful — when the consumer is an LLM or an automation pipeline.

Our design constraints were different:

1. Every output must be machine-parseable — JSON, always, no exceptions
2. No interactive prompts — if information is missing, fail with a clear error, don’t ask
3. Errors must be structured — JSON to stderr with error codes, not human-readable messages
4. Auth must be non-interactive — environment variables and flags, never browser redirects
5. Idempotent reads — running the same read command twice should always produce the same result

These constraints sound obvious. In practice, almost no construction software tooling follows them.

Why JSON-First Matters

When an AI agent calls procore projects list, it gets back a JSON array. No headers. No table formatting. No ANSI color codes. Just data.

This matters because:

• LLMs can parse JSON natively — no regex extraction, no brittle text parsing
• Downstream tools expect structure — piping to jq, feeding to another script, or storing in a database all work naturally
• Error handling is deterministic — a structured error object is actionable; a stack trace isn’t

We output errors to stderr as JSON too. An agent can distinguish between “auth failed” and “resource not found” programmatically, then take different recovery actions for each.

The Auth Problem

Both Procore and EagleView use OAuth2. The typical OAuth2 flow involves opening a browser, logging in, granting access, and handling a redirect. That’s fine for a human. It’s impossible for a headless agent.

Our CLIs handle this by accepting client credentials directly — via environment variables or flags. The CLI manages token exchange, refresh, and caching internally. The agent never touches a browser.

export PROCORE_CLIENT_ID="your-id"
export PROCORE_CLIENT_SECRET="your-secret"
export PROCORE_COMPANY_ID="12345"

procore projects list

That’s it. No interactive setup wizard. No config file ceremony. Set the variables, run the command.

What We Learned

Construction APIs are inconsistent. Procore scopes some endpoints to a company, others to a project. EagleView has different auth flows for different environments. Abstracting these inconsistencies behind a uniform CLI interface is where most of the work went.

Error messages matter more than you think. When an agent hits an error, it needs enough context to decide what to do next. “401 Unauthorized” isn’t enough. “Client credentials expired — re-authenticate with procore auth” is actionable.

Sandbox matters. Both CLIs support sandbox/production environment switching. This was critical for testing agent workflows without placing real orders or modifying real project data.

Try Them

Both CLIs are open source and available on npm:

• @opsrev/procore-cli — Procore API access from the command line
• @opsrev/eagleview-cli — EagleView measurement ordering and reports

If you’re building automation for construction software — whether with AI agents or traditional scripts — these might save you a few weeks of API wrestling.