Four Roles, One Pipeline
The evidence chain provides a way to read MathModelAgent’s retained backend: a role is valuable when it preserves the meaning a later role needs. This chapter follows the concrete path from question parsing through model design, code execution, and paper assembly. The goal is not to catalogue classes. It is to identify who owns each decision, what crosses each interface, and why the backend’s repair mechanisms improve protocol reliability without proving mathematical correctness.
The backend expresses the project’s broader separation through four roles. The Coordinator turns an unstructured problem into structured questions. The Modeler proposes how those questions should be represented and solved. The Coder implements and runs the proposed work. The Writer turns the resulting evidence into sections and a final document. They are not four independent assistants working on the same prompt. They form a serialized pipeline whose outputs become inputs to later stages.
Specialization works only when ownership is explicit
The Coordinator owns the first interpretation. It decides whether the request is a mathematical-modeling problem and attempts to organize the input into a title, background, question count, and question fields. That structure matters because the rest of the workflow needs to know how many subproblems exist and what each one asks. If the Coordinator merges two questions or invents a boundary that was not in the prompt, later roles can be internally consistent while solving a distorted problem.
The Modeler owns the next level of judgment. It receives the structured questions and returns a modeling solution for exploratory analysis, each question, and sensitivity analysis. Its prompt asks it to classify problem types, justify model choices, describe solving and validation strategies, and propose visualizations. It should not write the code. That boundary is useful because the model design can be inspected before the implementation starts, and because a coding failure can be distinguished from a flawed modeling proposal.
The Coder owns execution. In the current workflow it receives the Modeler’s solution for EDA, each dynamic question, and sensitivity analysis, then uses a persistent interpreter and tool calls to produce results and images. It can retry after execution errors and reports its outputs to the Writer. The Coder should not silently redefine the objective to make a program run. When it must deviate from a proposal, the evidence chain is strongest when that deviation is made visible rather than absorbed into an unrecorded prompt exchange.
The Writer owns communication and assembly. It receives the Coder’s response, interpreter output, and available image names for a subtask. It then writes the corresponding section and later fills front matter, problem analysis, assumptions, symbols, evaluation, and other configured sections. Its responsibility is not to invent missing evidence. It must translate what the earlier stages established into a reader-facing argument and preserve the limits that came with the result.
This division is more than a set of role names. It creates a boundary for diagnosis. A malformed question belongs first to interpretation. A method that cannot express the constraints belongs to modeling. A traceback belongs to execution. A number that changes while being copied into prose belongs to the writing or assembly transition. The boundaries do not eliminate shared responsibility, but they prevent every failure from being described vaguely as “the AI made a mistake.”
Handoffs turn free-form conversation into interfaces
The backend uses typed Pydantic models for its agent-to-agent handoffs.