Critical:
- Remove orphaned delegate_form_fill ToolOutput from OrchestratorAgent;
the method didn't exist and OrchestratorAgent(runtime) crashed at boot.
Also drop unused DocumentExtractorAgent import and KnowledgeUpdateResponse
from the OrchestratorResponse union. Form fill stays on its own endpoints
(POST /api/v1/form/ai/*) and is not wired as an orchestrator delegate.
Medium:
- Thread conversation_history through the three form-fill agents.
Contracts: FormAnalysisRequest, FormFillBatchRequest, and
DocumentExtractionRequest now carry conversation_history. Agents call
format_conversation_history() when building prompts, matching the
pattern from PdfQuestionAgent / PdfEditAgent.
- Add input bounds to form-fill contracts (max_length on strings,
min_length/max_length on lists and dicts). Caps: 50 files, 500 fields
per file, 20 documents per request, 500 knowledge entries, 50k chars
per document text, 8k chars per page text. Stops unbounded prompt growth.
- Replace Literal["fill_result"] / Literal["knowledge_update"] etc. with
WorkflowOutcome enum values. Adds KNOWLEDGE_UPDATE, MULTI_PROFILE_EXTRACTION,
and BATCH_FILL_RESULT to both WorkflowOutcome (Python) and
AiWorkflowOutcome (Java) to keep the "must stay in sync" contract honest.
Low:
- Drop duplicate build_test_settings() helper in test_form_fill_agent.py;
use conftest.build_app_settings() like the rest of the suite.
- Add test coverage for extract_multiple -> MultiProfileExtractionResponse
(the two-person detection path).
- ARCHITECTURE.md: clarify where state actually lives
(localStorage keys on the frontend, no user-scoping) and note that form
fill is not an orchestrator delegate.
128 engine tests pass. Lifespan boots cleanly with all four agents.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Resolution favours main for all conflicts (new orchestrator shape with
artifacts/file_names/conversation_history/resume_with, WorkflowOutcome
enum, RAG, ledger agent, deleted engine/config/.env.example).
Re-wires our three form-fill agents (FormAnalyserAgent, FormFillerAgent,
DocumentExtractorAgent) into the new app layout:
- contracts/__init__.py: adds form-fill exports to __all__
- api/dependencies.py: adds get_form_analyser_agent / get_form_filler_agent / get_document_extractor_agent
- api/app.py: instantiates the three agents in lifespan and registers form_fill_router
- api/routes/__init__.py: exports form_fill_router
- tests/test_stirling_api.py: imports and registers form-fill stubs
- tests/test_stirling_contracts.py: adds back KnowledgeUpdateResponse discriminator test
Form fill remains accessible via its own endpoints (/api/v1/form/ai/analyse,
/fill-batch, /extract). Not wired as an orchestrator delegate — following
main's pattern where orchestrator only routes pdf_edit/pdf_question/user_spec
/math_auditor.
Follow-ups still needed:
- Thread conversation_history into form-fill agent prompts
- Align form-fill response outcomes with WorkflowOutcome enum
- Decide whether engine should return ToolOperationStep plans (main's
new pattern per #6116) or keep returning fill values directly
All 127 engine tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
# Description of Changes
Add an extra parameter to every agent to receive the conversation
history in addition to the current message. This will make it possible
to answer followup questions from the AI without needing to give full
context in your message.
# Description of Changes
Redesign AI engine so that it autogenerates the `tool_models.py` file
from the OpenAPI spec so the Python has access to the Java API
parameters and the full list of Java tools that it can run. CI ensures
that whenever someone modifies a tool endpoint that the AI enigne tool
models get updated as well (the dev gets told to run `task
engine:tool-models`).
There's loads of advantages to having the Java be the one that actually
executes the tools, rather than the frontend as it was previously set up
to theoretically use:
- The AI gets much better descriptions of the params from the API docs
- It'll be usable headless in the future so a Java daemon could run to
execute ops on files in a folder without the need for the UI to run
- The Java already has all the logic it needs to execute the tools
- We don't need to parse the TypeScript to find the API (which is hard
because the TS wasn't designed to be computer-read to extract the API)
I've also hooked up the prototype frontend to ensure it's working
properly, and have built it in a way that all the tool names can be
translated properly, which was always an issue with previous prototypes
of this.
---------
Co-authored-by: Anthony Stirling <77850077+Frooodle@users.noreply.github.com>
Co-authored-by: EthanHealy01 <80844253+EthanHealy01@users.noreply.github.com>
# Description of Changes
Add Java orchestration layer which can connect and go back and forth
with the AI engine to get results for the user. It's expected that the
AI engine will not be publicly available and this Java layer will always
be in front of it, to manage sessions and auth etc.
# Description of Changes
Redesign the Python AI engine to be properly agentic and make use of
`pydantic-ai` instead of `langchain` for correctness and ergonomics.
This should be a good foundation for us to build our AI engine on going
forwards.
Reece