Introduction

• Allocating software engineers to tasks is a recurring, high-stakes management decision.
• Engineers differ in skills, cost and capacity; tasks differ in requirements, deadlines and priority.
• The right match determines whether a project succeeds — its quality, cost and delivery.

Why now?

• Open-weight LLMs have matured — capable models now run entirely on local hardware.
• This restores reproducibility (pin an exact model, not an API endpoint) and removes per-call cost and latency.
• It also opens a new question: how much does the choice of model matter for the quality of an agentic system's decisions?

Problem Statement

Given a set of engineers with heterogeneous skills and a set of tasks with specific requirements, assign engineers to tasks to optimize project criteria while respecting constraints:

• Skill qualification & proficiency
• Per-period capacity & availability
• Deadlines and a finite planning horizon
• Workload balance — avoiding both burnout and idle time
• Competing stakeholder objectives

Sets & Parameters

Decision Variables

• \(x_{eth} \ge 0\) — hours from engineer \(e\) on task \(t\) in period \(h\) (qualified pairs only)
• \(b_t \in \{0,1\}\) — task \(t\) is fully staffed
• \(y_t \in \{0,1\}\) — task \(t\) is completed on time

An effective-skill factor \(\bar{s}_{et}\) rewards over-qualification (capped at \(\rho\)): one hour of work yields \(\bar{s}_{et}\) units of effort.

Objective Function

Minimize labour cost + priority-weighted penalties for lateness and unstaffed work:

\[ \min\; \sum_{e}\sum_{t}\sum_{h} c_e\, x_{eth} \;+\; P_{\text{late}}\sum_{t}\pi_t\,(b_t - y_t) \;+\; P_{\text{drop}}\sum_{t}\pi_t\,(1 - b_t) \]

Choosing \(P_{\text{drop}} > P_{\text{late}}\) makes the solver leave a task unstaffed only when it is genuinely infeasible.

Constraints

Capacity — no more than available hours per period:

\[ \sum_{t} x_{eth} \le C_e\, a_{eh} \qquad \forall e, h \]

On-time delivery — enough effort by the deadline:

\[ \sum_{e}\sum_{h \le d_t} \bar{s}_{et}\, x_{eth} \ge w_t\, y_t \qquad \forall t \]

Plus assignment-linking (\(x_{eth} \le C_e b_t\)), ordering (\(y_t \le b_t\)) and structural skill qualification.

Solving the Model

• Fully linear — solved to proven optimality with the open-source CBC branch-and-cut solver via PuLP.
• No commercial license required.
• Hundreds of variables per instance — solved in < 1 second.
• Purpose: a provably optimal reference point for the optimality gap.

Design Principles

• Separation of judgement & feasibility — the LLM makes contestable choices; deterministic code enforces hard constraints.
• Single-variable comparability — one model instance drives all roles; roles differ only by system prompt.
• Bounded interaction — a state machine with a round limit and per-task attempt limit always terminates.

Agent Personas

All three roles are driven by the same shared model — only the system prompt differs.

Structured, Guarded Decisions

• Agents reply with validated JSON, not free-form text — robust for small local models.
• A hard feasibility guard blocks any capacity- or skill-violating assignment.

DEVELOPER_SYSTEM_PROMPT = """
You are {name}, a software engineer with a '{persona}' attitude.
Your skills (0-1): {skills}. Capacity: {budget} h; committed: {load} h.
Accept work that fits your skills and remaining capacity;
reject a poor skill match or a clear overload. Be decisive.
"""

The LLM shapes which feasible allocation emerges — never whether it is feasible.

LangGraph Orchestration

The allocation is a bounded state machine with conditional transitions.

LangGraph — Detailed Flow

System Architecture

C4 container view

Experimental Setup

• 18 reproducible instances — each fixed by a (size-class, seed) pair.
• Three size classes × six seeds:

Greedy decoding (temperature 0) → each model is deterministic per instance.

Four Open-Weight Models

Same harness, only the model changes — three regions, a wide range of scale.

Run locally on Apple-Silicon (MPS), half precision — no hosted API.

Evaluation Metrics

Both methods are scored by identical code:

• Completion & on-time rate
• Skill match and workload balance (CV, lower is better)
• Labour cost and the MILP objective value
• Optimality gap: \(100\,(z_{\text{agent}} - z_{\text{MILP}})/z_{\text{MILP}}\)
• Process cost: LLM calls & wall-clock time

Deterministic (MILP) Results

• Optimal in a mean of 0.12 s, never above 0.75 s.
• Completion 95.6% — only genuinely infeasible tasks left unstaffed.
• A tight, trustworthy lower bound on cost.

Multi-Agent Results

• Mistral-7B (EU): smallest gap and most balanced workload.
• Phi-4-mini (3.8B): matches larger models — fastest & smallest.
• Llama-3.1-8B: the laggard — more drops inflate its objective.

The Optimality Gap

How far above the MILP optimum — lower is better.

Completion & On-Time Delivery

Cost by Instance Size

The Cost of Transparency

Runtime and LLM-call volume per instance.

Behavioural Differences

Where the Gap Comes From

• The MILP optimises globally; the manager commits greedily, one assignment at a time, without backtracking.
• Locally reasonable choices are collectively sub-optimal — a cheaper global arrangement exists that no single local choice finds.
• Unplaced tasks incur the priority-weighted drop penalty, widening the gap.

Key Findings

• The multi-agent system lands within 7.0% of the optimum on average — best backend within 5.2%, but never reaches it.
• In exchange it makes trade-offs explicit through an auditable negotiation trace.
• The gap depends materially on the model — and capability does not simply track parameter count.

Practical Guidance

The optimiser answers “what is the least-cost feasible allocation?” — the agents answer “what allocation would these stakeholders plausibly agree to, and why?”

• MILP when cost and speed dominate and an unexplained answer is acceptable.
• Agents when transparency and stakeholder engagement matter.
• A natural hybrid: optimise first, then negotiate around the optimum.

Contributions

• A compact, fully linear MILP baseline solved to optimality.
• A multi-agent system with feasibility-guarded JSON decisions.
• A bounded LangGraph orchestration architecture.
• A controlled cross-model study — the model as a variable.
• A fully reproducible offline pipeline — every figure from the logs.