Skip to main content

Technical classifications

Technical classifications describe how an interpreter executes work, independent of its behavioral intent. Multiple technical approaches may be suitable for the same behavioral classification.

Understanding these categories helps implementers choose appropriate execution models while preserving contract quality and user expectations.

CLI-backed interpreters

CLI-backed interpreters invoke one or more command-line tools to perform work.

Typical characteristics:

  • Wrap existing, well-known CLIs
  • Translate intent into structured command invocation
  • Capture and normalize results
  • Absorb CLI-specific churn and platform differences

These interpreters must take special care to avoid exposing raw flags or positional arguments directly through the contract.

API-backed interpreters

API-backed interpreters interact with external services or systems through APIs.

Typical characteristics:

  • Translate intent into API requests
  • Manage authentication and authorization internally
  • Normalize API responses into stable structured output
  • Shield users from API versioning and protocol changes

These interpreters are commonly used for SaaS integrations and remote system management.

Runtime-backed interpreters

Runtime-backed interpreters execute logic within an embedded runtime environment.

Typical characteristics:

  • Use language runtimes or SDKs directly
  • Perform in-process computation or evaluation
  • Avoid external process invocation
  • Provide high performance and tight execution control

These interpreters are often used for policy evaluation, data transformation, or complex logic that doesn’t map cleanly to a CLI or API.

Composite interpreters

Composite interpreters combine multiple engines or execution approaches internally.

Typical characteristics:

  • Coordinate multiple CLIs, APIs, or runtimes
  • Encapsulate multi-engine workflows
  • Present a single, unified contract and outcome

Composite interpreters must be especially careful to preserve clear intent and avoid leaking internal complexity.

Native interpreters

Native interpreters are implemented directly against the Courier execution environment without relying on external tools.

Typical characteristics:

  • Minimal external dependencies
  • Tight integration with Courier Runner capabilities
  • Strong control over execution and output
  • Long-term stability and portability

Native interpreters are often used for core platform capabilities or performance-sensitive operations.

Thank you for your feedback!

×