Skip to content

A Declarative Language for Building And Orchestrating LLM-Powered Agent Workflows

🕒 Published (v1): 2025-12-22 05:03 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

This paper presents a declarative DSL (embedded in a fluent Java builder) that compiles agent workflows to a language-agnostic JSON intermediate representation, enabling the same pipeline to execute across Java, Python, and Go backends. Evaluated on real PayPal e-commerce traffic (millions of daily interactions), the system demonstrates 67% reduction in development time and 30% fewer LLM steps to completion versus imperative baselines. The core insight is that most agent workflows reduce to a fixed set of composable primitives (iteration, conditionals, tool invocation, marshaling) that can be expressed declaratively rather than programmatically.

Problem

Existing LLM agent frameworks (LangChain, LangChain4j, NeMo, AutoGPT) tightly couple agent logic to a specific programming language, require full redeployment for behavior changes, and lack enterprise-grade observability, security context propagation, and A/B testing support. This makes production deployment fragile and prohibitively expensive to maintain in heterogeneous enterprise environments.

Method

The system defines agent workflows as DAGs over a grammar of pipeline steps: passVars, setValue, forEach, when, toolRequest, addMessage, addResponse, function, return. A fluent builder pattern compiles these to a JSON IR that is statically analyzed (dead code elimination, undefined variable detection, cyclic dependency checks) and interpreted by a language-agnostic executor. The executor implements:

  • Hybrid sync/async execution: sequential steps share an immutable variable store; parallel steps run in isolated contexts with deterministic result merging.
  • Tool/function distinction: tools are LLM-discovered and invoked via toolRequest; functions are deterministically called by the pipeline itself, enabling precise control over autonomous vs. fixed computation paths.
  • Hot-reload: pipelines are loaded from external storage (DB/cache) without service restart, enabling instant rollback.
  • Optimization passes: dead code elimination, pipeline fusion, parallel segment identification via dependency analysis, LLM response caching with TTL-based invalidation.

Key Contributions

  • Language-agnostic declarative DSL with formal grammar and small-step operational semantics for core constructs.
  • Hybrid execution model separating LLM-driven tool selection from deterministic function calls.
  • Compile-time static validation (structural, variable flow, tool signature checking) plus runtime type coercion and schema validation.
  • Native A/B testing support: multiple pipeline variants run on the same infrastructure with automatic metric collection.
  • Production deployment at PayPal handling millions of daily e-commerce agent interactions.

Results

Against an imperative baseline on 1,000 real customer sessions (gpt-4o backend):

  • Task success rate: 78% → 89% (+11pp)
  • Avg. steps to completion: 9.2 → 6.4 (−30%)
  • Lines of code: 850 → 220 (−74%)
  • Development time: 48 → 16 hours (−67%)
  • P95 latency: 240ms → 185ms (−23%)
  • Modification time (add/change a tool): 8.5 → 2.0 hours (−76%)
  • Multi-intent case study: 6 pipeline steps vs. 11 imperative steps for a search→add-to-cart→coupon session.

Limitations

  • Evaluation limited to 1,000 sessions in a single domain (e-commerce); no cross-domain or cross-system comparisons.
  • No comparison against other declarative agent systems.
  • Pipeline execution adds 10–20ms interpretation overhead versus compiled code.
  • No native reinforcement learning or online adaptation; agents cannot self-improve without external intervention.
  • Long-term cross-session memory requires awkward workarounds (vector DBs, knowledge graphs) that break declarative abstraction boundaries.
  • Debugging nested/async pipelines is difficult; stack traces through sub-pipelines obscure error origins.
  • LLMs are treated as black boxes; no mechanism to expose or validate internal reasoning for explainability.
  • Single deployment environment for performance metrics; scalability claims are partly theoretical.

Relevance to Harnesses / Meta-Harnesses

This paper is a direct instantiation of the harness pattern: a meta-layer that compiles a high-level workflow specification into executable orchestration logic across heterogeneous backends. The JSON IR plays the role of a harness configuration artifact—versionable, diffable, interpretable—that decouples the "what" (pipeline logic) from the "how" (runtime, language, deployment). Hot-reload, A/B variant execution, and automatic metric collection are precisely the concerns that distinguish a production meta-harness from a simple agent runner. The explicit grammar and formal semantics provide a rare foundation for verifying harness correctness properties (termination, variable safety) rather than relying on empirical testing alone.