Python Developer for AI Middleware

# Python Developer for AI Middleware / Game Integration Project ## Project Overview We are developing a mod for Bethesda's *Starfield*. The project will add an in-universe communications system that allows players to exchange persistent text messages with AI-driven fictional characters. The project will use a separate local Python middleware application to handle the AI functionality. Starfield-specific integration will be handled separately through Papyrus/SFSE and is not expected to be the Python developer's responsibility. The project is currently in the design/specification phase. Detailed requirements, architecture documentation, interface specifications, acceptance criteria, and development milestones will be provided before implementation begins. ## Middleware Responsibilities The Python middleware is expected to handle areas including: * LLM provider integration, initially including an OpenAI-compatible API such as OpenRouter * Support for local models may be added later * Persistent contacts and character profiles * Conversation storage and retrieval * Long-term character memory * Relationship state * Context/prompt construction * Structured game-state input * Asynchronous message processing * Contact-initiated messages and scheduling * Response validation and regeneration * Prevention of AI responses that contradict defined world-state constraints * SQLite persistence * Configuration and API credential handling * Logging and diagnostics * A defined IPC interface between the middleware and a separate Starfield/SFSE component * Potential future vision/image-generation functionality The architecture should keep AI providers modular so that individual providers can be replaced or added without redesigning the application. ## Technical Direction The current planned architecture is approximately: Starfield → Papyrus / SFSE bridge → local IPC → Python middleware → SQLite / memory / character system → LLM provider The middleware will expose a documented protocol to the Starfield integration layer. Early development may use a simple test harness or file-based interface so that most middleware development and automated testing can occur without requiring Starfield to be installed or running. ## What We Are Looking For Strong Python development experience is required. Particularly relevant experience includes: * Python application architecture * REST/HTTP APIs * LLM APIs * structured prompting * conversational memory systems * SQLite * JSON * asynchronous programming * IPC * automated testing * secure API credential handling * packaging Python applications for Windows Experience with retrieval systems, embeddings/vector search, image-generation APIs, or vision-capable models would also be useful. Experience with Starfield, Bethesda modding, Papyrus, SFSE, C++ or Scaleform is a bonus but **not required**. We would rather hire an excellent Python/AI developer than a game modder with mediocre Python skills. ## Development Expectations This project will be maintained in a Git repository owned by us. At a minimum, the repo must be updated daily. Automated tests are expected for appropriate components. Code should be reasonably modular, documented and maintainable by another competent developer. Production dependencies should be kept reasonable and documented. API credentials must be handled securely and must never appear in source control or diagnostic logs. Significant architectural changes should be discussed before implementation rather than made unilaterally. Relevant technical documentation must be updated when implementation changes the documented architecture or interfaces. Dependencies and libraries must have licenses compatible with redistribution. ## Project Structure We expect to structure the engagement as a **fixed-price project with individually funded milestones**. Each milestone will have: * defined requirements * specific deliverables * acceptance criteria * required automated tests where applicable * source code committed to the project repository * required documentation updates Milestones will be reviewed and accepted before the next milestone begins. The initial paid milestone will intentionally be relatively small. If the work and collaboration are good, we expect there to be substantial additional middleware work available through subsequent milestones. We are not looking for someone to estimate and commit to the entire finished application based solely on this job post. ## When Applying Please answer the following questions: 1. Briefly describe a Python project you have built that involved an LLM API or another asynchronous external API. 2. How would you approach long-term memory for an AI character that may accumulate hundreds or thousands of messages without sending the entire conversation history with every LLM request? 3. How would you structure the application so that OpenRouter, a local model, or another LLM provider could be substituted without rewriting the character/memory system? 4. What would you recommend for persistent local storage for this application, and why? 5. Have you packaged Python applications for non-technical Windows users? If so, what approach did you use? 6. Have you implemented inter-process communication in Python? If so, what mechanism(s) have you used? 7. How do you normally structure automated tests for applications that depend on paid/external APIs? 8. Are you comfortable working from detailed written requirements and acceptance tests under fixed-price milestones? 9. Please provide your normal hourly rate for comparison purposes, even though this project is expected to use fixed-price milestones. 10. After reading this description, identify one technical issue, risk, or architectural question you think should be resolved before significant development begins. Please do not provide a generic AI-generated proposal. We are particularly interested in your answers to Questions 2, 3, 7 and 10 because they will help me evaluate how you think about the architecture rather than simply whether you have used an LLM API before.