Crixeia

Closing the Golden Hour gap in livestock disease outbreak response

Comment

Inspiration

I've heard stories of how livestock farmers (especially poultry farmers) lose their flocks or herds overnight due to disease outbreaks in the farms that could have been contained if anyone had acted faster. As someone who plans to go into livestock farming in the future, this is a threat that I definitely do not want to face. The first 60 minutes of detection of a high-consequence livestock disease event is when the difference between a contained incident and a regional catastrophe is decided. Today, a farm operator facing a suspected HPAI or African Swine Fever outbreak must simultaneously identify the disease, quarantine affected pens, notify appropriate bodies (e.g. state veterinarians, contact USDA APHIS for the US and NVQS, NCDC for Nigeria) alert neighboring farms, and file insurance notices, all while managing a panicked situation on the ground. This process may take hours to days. Notifications get missed and quarantine zones are drawn incorrectly. The disease spreads across far and wide before a single official is even aware it exists.

I built Crixeia to close that gap.

What it does

Crixeia is an AI biosecurity operations platform for livestock farms. It continuously monitors pen-level environmental sensors and individual animal bio-telemetry across registered farm nodes, storing all readings in MongoDB Atlas — structured as a hybrid collection model with pen-level documents tracking ambient conditions (temperature, humidity, feed consumption) and individual animal documents for the 10% of livestock carrying high-precision bio-telemetry nodes. When anomalous sensor patterns are detected, Crixeia activates an autonomous crisis response workflow that's powered by Google's Gemini 3.1 Pro Preview model via Vertex AI. The agent uses vector similarity search against MongoDB-stored disease profile embeddings to identify the suspected pathogen. In a single activation, the AI agent (through the MongoDB MCP Server as its database interface):

  1. Queries the outbreak_events collection to load full farm and outbreak context
  2. Runs vector similarity search across disease_profiles to identify the disease with a confidence score
  3. Uses mongodb_update_one to escalate the outbreak record from "suspected" to "confirmed", writing the identified disease name and confidence score directly into the document
  4. Generates a farm-specific biosecurity and quarantine plan based on the confirmed disease and affected pen layout.
  5. Uses mongodb_insert_one four times to populate the notification_queue collection with tailored emergency drafts for the State Veterinarian, USDA APHIS, neighboring farms, and the insurance provider — each document structured with stakeholder type, priority level, and full message content

All four drafted communications appear instantly in the Approval Queue, where the farm operator reviews each AI-generated notification, can edit the content inline, view the full data trace, and approve or reject with a single click. Nothing is dispatched without human sign-off — MongoDB's notification_queue collection is the human-in-the-loop checkpoint between AI reasoning and real-world action.

How we built it

AI Agent: Google ADK + Gemini 3.1 Pro Preview The crisis agent is built with Google's Agent Development Kit (ADK). It runs on Gemini 3.1 Pro Preview via Vertex AI. The agent uses a multi-step reasoning loop: disease identification via vector search, quarantine plan generation, and stakeholder notification drafting.

MongoDB MCP Server: The Agent's Hands The MongoDB Model Context Protocol (MCP) server acts as the operational layer between the AI's intelligence and the database. Rather than writing a fixed API endpoint for every database action the agent might need, the MCP server gives the agent a schema-aware toolset it can use autonomously.

The agent performs two specific high-value operations through MCP:

mongodb_update_one When analysis completes, the agent finds the outbreak record by ID and escalates it: writing the confirmed disease name, confidence score, and changing status from "suspected" to "confirmed". The agent decides when and how to do this based on its reasoning, not a hardcoded trigger.

mongodb_insert_one For each stakeholder, the agent inserts a new notification document into the human-in-the-loop queue. It structures each document with the appropriate priority, message content, and routing metadata. This turns the database into a set of autonomous capabilities the agent manages itself.

Infrastructure

  • Backend: FastAPI + Motor (async MongoDB driver), deployed on Google Cloud Run
  • Frontend: Next.js 15 with App Router, deployed on Google Cloud Run
  • Database: MongoDB Atlas (Cape Town cluster) with GeoJSON location indexing
  • Authentication: Vertex AI Application Default Credentials
  • Secrets: Google Cloud Secret Manager

Monitoring Architecture Hybrid model reflecting real-world constraints: pen-level IoT sensors for environmental metrics (temperature, humidity, feed consumption, water intake) across all animals, plus high-precision bio-telemetry on 10% of animals per farm (individually tracked with temperature, weight, and activity data).

Challenges we ran into

The biggest technical challenge was the Vertex AI endpoint for newer Gemini models. Gemini 3.1 Pro Preview is only available on the global endpoint, not regional endpoints like us-central1. The Google ADK was constructing the URL as global-aiplatform.googleapis.com (which doesn't exist) instead of aiplatform.googleapis.com. The fix required explicitly calling vertexai.init(project, location='global') before ADK initialisation to set the SDK's internal state correctly before any client objects were created.

The second challenge was Google Cloud organisation policies inherited by the initial project, which blocked API key authentication and Vertex AI access. The solution was creating a new project under "No organisation".

Another challenge was the learning curve I had to go through as a first-time MongoDB user e.g., compatibility issues with different versions of motor and pymongo. After, that learning curve, the experience with it has been quite smooth.

Accomplishments that we're proud of

  1. I met the deadline!!!
  2. The first hackathon I'm successfully submitting
  3. I learned to really finetune an AI agent to give results. Crixeia doesn't just give generic advice; it analyzes the specific farm species and pathogen type to generate localized containment steps that are actionable. So, I can say my skills as regards building AI agents has been polished significantly.

What we learned

  1. I learned how to integrate MCP tools into a FastAPI environment to give AI agents, structured access to a database.
  2. Deployment on Google Cloud Run is no longer as stressful as I used to think. I'm now able to resolve errors easily.

What's next for Crixeia

The future of Crixeia would include:

  • Real IoT sensor integration (the data model and API are already structured for it)
  • Calculated readiness scores based on vaccination compliance, historical incidents, and sensor coverage -Audits and Audit Logs
  • Geographic threat map showing outbreak proximity across regional nodes
  • Mobile app for farm operators to receive and approve notifications in the field
  • Automated dispatch integration with state veterinary notification systems
  • Crixeia for Humans (Global Pandemic Simulation): A "War Room" mode for regional governments to simulate

Built With

  • fastapi
  • gemini-3.1-pro-preview
  • google-adk
  • google-cloud-run
  • google-vertex-ai
  • mongodb-atlas
  • mongodb-mcp-server
  • motor
  • next.js
  • python
  • typescript
Share this project:

Updates