University

AI Workflow DSL

AI Workflow DSL makes multi-agent workflows readable as a small language instead of ordinary orchestration code. Its first phase implements tokenization, a generated LL(1) parse table, a stack parser, synchronized grammar docs, and source-aware errors.

Technologies used

Python
Lexer & Parser
Parse-table Generation
unittest

A valid workflow passes through a source-aware lexer, a generated LL(1) table, and a stack parser.

AI Workflow DSL overview showing a workflow program beside the lexer, generated LL(1) table, and stack parser — A valid workflow passes through a source-aware lexer, a generated LL(1) table, and a stack parser.

Syntax errors reuse token positions and parse-table state to show where parsing stopped and what could continue the program.

AI Workflow DSL diagnostic showing a missing brace error with its location, found token, expected terminals, and parser state — Syntax errors reuse token positions and parse-table state to show where parsing stopped and what could continue the program.

A workflow becomes the program

AI Workflow DSL is the first phase of an EECE 334 language-design project. It expresses agents, tools, typed task signatures, and orchestration blocks as a compact program that can be checked before any workflow runs.

I kept this phase focused on syntax analysis. The implementation accepts the required language subset and reports malformed input, while AST construction and semantic checks remain explicit next steps.

One grammar drives the implementation

The grammar lives as 60 numbered productions in Python. That same structure computes FIRST and FOLLOW sets, builds the predictive parsing table, and generates the Markdown grammar documents. A grammar edit therefore changes the parser and its written artifacts through the same source.

The language is shaped for LL(1) parsing. Optional sequences use explicit nonterminals, comma-separated values use tail productions, and expressions are split into precedence levels. Run calls have their own assignment branch so the parser can choose a production with one token of lookahead.

agent Researcher {
    tool web_search

    task gather(string topic) -> string data {
        action: web_search(topic)
    }
}

system {
    string data = run Researcher.gather("AI")
}

A table-driven parser with useful failure states

The lexer uses one master regular expression and records each token's original text, line, and column. The parser keeps an explicit symbol stack, expands nonterminals from the generated table, and matches terminals against the token stream.

When a production is unavailable, the parser already knows the valid terminals for that state. The error object combines those expectations with the current token position, so failures identify the location, the value that was found, and the alternatives the grammar permits.

Verification and deliberate limits

The repository includes valid programs for single-agent and nested workflows, plus invalid programs covering missing braces, malformed task headers, bad lists, illegal statements, and missing system blocks. The unittest suite checks both groups and verifies that generated documentation still matches the grammar.

The current parser returns an acceptance result and token count. It does not build an AST, resolve agent and task names, or check type compatibility. A second phase could add those semantic passes without changing the lexer or the grammar-driven table generation.