CEF 2026 Pre-conference — Meeting Summary

A summary of the SCE pre-conference on computational economics toolkits and interoperability, held 28 June 2026 at Ca’ Foscari University of Venice. This page is intended both as a record for those who attended and as an overview for those who could not.

Key takeaways¶

• The pre-conference focused on the challenge of interoperability among computational economics toolkits, framed as a “Tower of Babel” problem.

• Project Bellman (presented by Akshay Shanker) proposes a declarative syntax and semantic-graph approach to represent dynamic programming problems, enabling AI (LLMs) to assist with code generation and toolkit interoperability via a “Rosetta Stone” framework.

• Matt McKay (QuantEcon) proposed building a community reference library for computational economics — a single, open-source, cross-toolkit resource with shared baseline models and hero tutorials.

• Sébastien Villemot presented lessons from Dynare’s 30-year history, emphasizing DSL design, open source, community governance, and sustainable funding.

• Panel discussants highlighted tensions between declarative and imperative coding paradigms, the role of AI in lowering interoperability costs, and the need to keep computational tools aligned with economic questions.

• Three working groups were proposed: (1) explaining economics problems to AI, (2) constructing Rosetta Stones for toolkit interoperability, and (3) reproducibility and standards.

Discussed topics¶

1. Opening remarks and motivation: the Tower of Babel problem¶

Chris Carroll (Johns Hopkins) opened the session by framing the core challenge: the proliferation of computational economics toolkits creates a communication barrier — a modern Tower of Babel — where tools cannot easily interact. He referenced the Hitchhiker’s Guide to the Galaxy’s “babel fish” as a metaphor for what AI could become for the field.

• Recent advances in AI (within the last six months) are powerful enough to help solve the interoperability problem if given sufficient structural information about the kinds of problems economists solve.

• The session was structured in three parts — a presentation on Project Bellman, a presentation by Sébastien Villemot on Dynare’s lessons, and a panel discussion with toolkit developers.

• Three working groups will be formed: (1) explaining economics to AI, (2) building Rosetta Stones for cross-toolkit communication, and (3) reproducibility and standards integration.

Conclusion: AI, combined with structured representations of economic problems, is seen as the key enabler for overcoming toolkit fragmentation. All participants and broader conference attendees are encouraged to sign up for at least one working group.

2. Project Bellman: declarative syntax, semantic graphs, and the Rosetta Stone¶

Akshay Shanker presented Project Bellman, a framework aimed at creating a declarative syntax and semantic representation for dynamic programming problems to enable AI-assisted interoperability.

• Interoperability in economics (specifically economic dynamics) is far lower than in fields like machine learning (>90%), quantum chemistry (>60%), and operations research (>70%). Only ~15% of economics papers borrow non-trivial solver code from established toolkits, and this is dominated by Dynare.

• Economics is also less diverse in its numerical methods than other fields, suggesting that low interoperability is partly an incentive problem.

• A key proximate cause of low interoperability is a “procedural attitude” to coding — methods and models become bundled together, making it impossible to cleanly separate and swap components.

• Project Bellman introduces a declarative syntax (inspired by Dynare/Dolo) and an elaboration step that converts syntax into a semantic graph — a structured representation of Bellman operators using type theory.

• The core abstraction is the “stage,” composed of three objects — arrival, decision, and continuation — which generalizes Markov Decision Processes and can represent any Bellman operator.

• Stages compose into periods, and periods compose into a “trellis” (borrowed from computer science), forming a full graphical representation of the dynamic programming problem.

• The Rosetta Stone is a repository/graph of operator signatures and their implementations across toolkits (currently including QuantEcon, HARK, and Dolo), enabling LLMs to identify how a given semantic graph can be solved using existing toolkit code.

• An LLM assistant (referred to as “Matthea”) is being developed to handle master prompts, suggest solver factorizations, and generate pseudocode or code from semantic graphs.

• The current scope of the syntax/semantic approach is single-agent problems without general equilibrium.

• Users can interact at multiple levels — writing plain syntax, calibrating and methodizing, or manually walking through the Rosetta Stone.

Conclusion: the elaboration step (syntax → semantic graph) is the critical innovation enabling AI to understand and act on economic model structure. The Rosetta Stone does not require all toolkits to rewrite their code — LLMs can identify relevant components even from non-standardized codebases. Access to a “smart cell” with initial API credits will be made available to participants shortly after the conference.

3. QuantEcon community reference library proposal¶

Matt McKay (QuantEcon) presented a proposal for a community-owned, cross-toolkit, open and executable reference library for computational economics.

• There are over a dozen mature toolkits across MATLAB, Python, and Julia, but no shared reference, no easy way to compare them, and no common on-ramp for researchers and students.

• The proposed library would be community-owned (each project authors and maintains its own content), cross-toolkit (same canonical models solved side by side), and open and executable (published via JupyterBook with runnable code).

• Each project would contribute two things: a shared baseline model (e.g., an Aiyagari model with agreed parameters and calibration targets) and a “hero tutorial” showcasing the toolkit’s unique strengths.

• Shared baseline models would serve as a substrate for AI assistance and a proving ground for emerging standards like Project Bellman’s schema.

• QuantEcon reaches ~31,000 users per month across 172 countries and can provide infrastructure (CI integration, GitHub collaboration, JupyterBook hosting, MATLAB kernel support).

• A two-phase roadmap was proposed — Phase 1: build the community library with two baseline models and one hero tutorial per toolkit; Phase 2: leverage the library for AI assistance and shared schema development.

• Discussion (Chris Carroll): having common examples solved by different tools is key to building the Rosetta Stone that AI can use automatically.

• Discussion (Robert Kirkby): most toolkits likely already have Aiyagari and three-equation New Keynesian examples; the main task is harmonizing notation and parameters rather than writing from scratch.

• Discussion (Pablo Winant): raised whether old QuantEcon Jupyter notebooks (from the notes.quantecon.org platform) could be incorporated; Matt confirmed those notebooks are still on GitHub and could be reviewed for inclusion, particularly as hero-tutorial candidates.

Conclusion: the library would serve as a shared home, entry point, and comparison resource for the computational economics toolkit ecosystem. Whether this initiative fits under an existing working group or warrants a fourth working group was left open. Matt offered to participate across multiple working groups as an observer.

4. Lessons from Dynare: DSL design, interoperability, and governance¶

Sébastien Villemot (Dynare Team) presented a detailed account of Dynare’s 30-year history, its domain-specific language (DSL), interoperability features, and institutional lessons.

• Dynare’s mission is to allow the average economist to write their model almost as they would on paper — a novel idea 30 years ago, now less exceptional given LLMs.

• Dynare handles DSGE models (RBC, representative agent, RANK, TANK), recently added heterogeneous-agent model support, and also handles semi-structural models (e.g., FRB-US style).

• The Dynare DSL is declarative, separates model description from computational tasks, and avoids requiring users to distinguish state and control variables.

• The DSL supports aggregate models specified as first-order conditions or as maximization problems (with FOCs derived automatically), regime switching (mixed complementarity problems and equation tags), and heterogeneous-agent models (with new keywords for idiosyncratic variables and a sum operator).

• The DSL has proven extensible to heterogeneous-agent models despite not being designed for them 30 years ago; further extensions (multiple heterogeneity dimensions, continuous time, Bellman-type specification) are feasible at the language level.

• Dynare’s interoperability offerings include: preprocessor outputs (a JSON file with declarations, model residuals and derivatives in MATLAB/Octave/Julia/Python/JSON) for use by other tools; load commands for importing steady states, scenarios, and data from other tools; and LLM fluency enabled by extensive forum and documentation material, plus a forthcoming official Language Server Protocol (LSP).

• Dynare does not currently offer a stable internal API (it is an integrated software, not a library), which limits its use as a component in other systems.

• The XKCD “standards” cartoon was shown to illustrate the risk that attempts at unification can proliferate rather than consolidate standards; unifying around a single DSL is likely unrealistic for both technical and social reasons.

• Key DSL design principles: closeness to economist concepts, declarative not imperative, separation of model description from computation, simplicity, extensibility, and stability (backward compatibility).

• Institutional and social factors were critical to Dynare’s success — industrial-quality development processes, a sustained team, structured change management, open source (GPL), documentation, governance, community building (forum, training schools), and a sustainable funding model (primarily central-bank sponsorships and service contracts).

• Cherrier, Saidi, and Sergi (JEDC, 2026) frame Dynare as a “digital commons” in the Ostrom sense — a shared resource governed by community institutions.

• Dynare’s success is partly path-dependent — early institutional movers (especially the IMF), timing of estimation features, and open source were critical; early DSL design mistakes are hard to fix due to backward-compatibility constraints.

Conclusion: key lessons for the standards agenda — open source is essential; separate model description from computation; standards emerge endogenously but can be catalyzed by institutional adopters; invest heavily in language design upfront, as path dependence is real. The Dynare DSL could potentially serve as a base for a standard, but technical and social challenges should not be underestimated.

5. Panel discussion: toolkit developer perspectives¶

Panelists are identified below from the pre-conference participant roster (Zoom’s automatic transcription garbled several names).

Bence Bardóczy — Sequence-Space Jacobian (Federal Reserve Board):

• SSJ deliberately chose not to use a text-based model file processed by a preprocessor, instead working in native Python for easier setup, rapid debugging, and user flexibility.

• For heterogeneous-agent models, the declarative paradigm has limits — users need fine-grained control over grid design, monotonicity exploitation, and other optimizations that are hard to automate.

• SSJ’s “bring your own Jacobian” feature allows users to compute Jacobians in any language or method and plug them into the SSJ framework for sequence-space aggregation, inversion, and impulse-response computation.

• Takeaway: the tension between declarative convenience and imperative flexibility is particularly acute for heterogeneous-agent models; modular, bring-your-own-component designs can facilitate interoperability without requiring full standardization.

Pablo Winant — Dolo / Dolark (CREST / Bank of England):

• LLMs can already write Dynare code for simple models when given a model description, and this capability will expand rapidly.

• A structured way of describing models (e.g., by actor type, market structure, price determination) could help LLMs handle more complex models.

• Finding steady states for complex multi-industry models with nested CES production functions remains a hard problem that LLMs cannot yet automate reliably.

• Models in linearized form (as in Volker Wieland’s macromodel database) are error-prone; automatic differentiation from nonlinear models is preferable.

• The key question is at which level of mathematical representation to standardize — it must be extensible to new market structures and information structures.

Robert Kirkby — VFI Toolkit (Victoria University of Wellington):

• AI is already capable of identifying which toolkit to use for a given model and generating working code, but it makes systematic mistakes in selecting algorithm options and defaults.

• Toolkits need to do more work on hard-coding sensible defaults based on model structure, and on warning users when non-default settings are likely needed.

• With AI coding, backward compatibility is less important than it used to be — users can ask AI to update code to the latest version, so toolkit developers should feel free to break and rebuild when needed.

Matt McKay — QuantEcon (ANU; remote):

• AI works best when given a valid set of goals, controlled inputs, and a clear path from A to B — exactly what the Rosetta Stone and Project Bellman provide.

• The community reference library could serve as a training substrate for LLMs, providing expert-curated, verified baseline models as guidelines.

• A layered approach is needed — AI for translations and toolkit switching, but with expert editorial oversight for the last 10% of accuracy.

• QuantEcon’s experience with AI-assisted translation of lecture content confirms the value of AI getting 90% of the way, with expert editors verifying the rest.

Guangyu Nie — GDSGE (Shanghai University of Finance and Economics; toolkit by Wenlan Luo and Dan Cao):

• GDSGE focuses on global solutions with finite agents, using a gmod file (inspired by Dynare) that generates C++ and MATLAB code.

• A user reported that the toolbox is valuable precisely because AI can generate gmod files that are easy to proofread, while the toolbox handles the complex backend — separating human verification from automated computation.

• The toolbox is open source on GitHub, but the small team lacks manpower for maintenance and user education.

• Over 80% of user inquiries are about global solution methods in general, not the toolbox specifically — suggesting a need for community forums and educational resources.

Junior Maih — RISE (Norges Bank):

• Most economists are not programmers — they want to write papers and move on, not maintain elegant software.

• A toolkit that solves all problems is an illusion given the constantly evolving environment (new modeling needs, numerical methods, hardware/software ecosystems).

• There is a risk of drowning in technicalities and becoming increasingly irrelevant to policymakers.

• AI can help economists write clearer code, automate boilerplate, and focus on economics — but it is a complement to expertise, not a replacement.

• A sustainable ecosystem requires modest and realistic standards, interoperability where it matters, transparency in numerical methods, governance not reliant on a few individuals, and a focus on economic purpose over machinery.

6. Working group structure and organization¶

• Three working groups are planned: (1) explaining economics problems to AI, (2) constructing Rosetta Stones for cross-toolkit interoperability, and (3) reproducibility and standards.

• Herbert Dawid was nominated to chair the second working group, partly due to his connections to the agent-based modeling community, an important constituency.

• Matt McKay’s community-library proposal spans multiple working groups and may warrant either integration into an existing group or creation of a fourth working group.

• Pablo Winant suggested framing the overall effort as a research program rather than a list of tasks — a suggestion Chris Carroll endorsed.

• Sign-up sheets for the working groups were made available at the end of the session; all participants are encouraged to join at least one.

Challenges¶

• Interoperability gap: economics has far lower toolkit interoperability (~15%) compared to machine learning, quantum chemistry, and operations research (50–90%), driven by incentive structures and a procedural coding culture.

• Declarative vs. imperative tension: for heterogeneous-agent models, fully declarative approaches may sacrifice the fine-grained user control needed for efficient solutions.

• Steady-state computation: automating steady-state finding for complex multi-industry models with nested production functions remains hard and not yet solvable by LLMs.

• AI default selection: current AI systems are poor at selecting appropriate algorithm options and defaults within toolkits, limiting the quality of AI-generated code.

• Backward compatibility vs. language improvement: fixing early DSL design mistakes conflicts with the stability that keeps users on current versions.

• Sustainability of small toolkit teams: teams of two or three developers cannot adequately maintain tools, respond to inquiries, or educate new users at scale.

• Scope of Project Bellman: the current framework covers only single-agent problems without general equilibrium; extension to GE and agent-based models is a significant open challenge.

• Platform fragmentation: the ecosystem spans MATLAB (licensed), Python, Julia, and C++, creating infrastructure challenges for a unified community library.

• Funding sustainability: long-term maintenance requires stable funding beyond research grants; Dynare’s central-bank-sponsorship model may not generalize to all toolkits.

• Risk of irrelevance: increasing technical complexity risks widening the gap between computational tools and the questions policymakers need answered.

Action items¶

Akshay Shanker

• Provide access to the Project Bellman “smart cell” with initial API credits to all pre-conference participants within the next few days to a week.

• Send access information to interested participants not on the pre-conference list (via the admin email).

• Collect papers and models from participants to help build and train the Bellman system.

Matt McKay

• Set up a registration/interest form for the community reference library proposal and share it with all working groups.

• Collaborate with toolkit projects to define shared baseline models (e.g., Aiyagari, three-equation New Keynesian) with harmonized parameters and calibration targets.

• Review the old notes.quantecon.org Jupyter notebook repository (currently on GitHub) for potential inclusion as hero tutorials.

• Explore infrastructure solutions for MATLAB users (e.g., local kernel connection via website).

• Participate across working groups as an observer to collect community needs.

Chris Carroll

• Share all web pages and materials presented during the session with all participants.

• Finalize the working group structure — determine whether Matt’s community-library proposal fits under an existing working group or warrants a fourth.

• Coordinate with Herbert Dawid on chairing the second working group (Rosetta Stone / interoperability), ensuring agent-based-modeling representation.

• Set up sign-up sheets for the working groups.

• Frame the overall initiative as a research program (per Pablo Winant’s suggestion) and distribute the relevant web page to participants.

Sébastien Villemot / Dynare Team

• Publish the official Language Server Protocol (LSP) for the Dynare DSL (currently in development; a third-party version already exists).

• Consider developing a stable internal API for Dynare to enable its use as a library component in interoperability frameworks like Project Bellman.

Herbert Dawid

• Chair the second working group on Rosetta Stone construction and cross-toolkit interoperability, with particular attention to bridging the agent-based-modeling and DSGE / heterogeneous-agent communities.

All toolkit developers / participants

• Sign up for at least one working group.

• Consider contributing a shared baseline model and a hero tutorial to the QuantEcon community reference library.

• Review existing toolkit examples (e.g., Aiyagari, three-equation New Keynesian) for harmonization of parameters to enable cross-toolkit validation.

Source: Zoom AI Companion meeting summary for “SCE Preconference on Economics Toolkits,” 28 June 2026. Auto-generated and lightly edited; please report any corrections.