INDRA: Your infrastructure companion

Inspiration

When a service slows down, operations teams need answers quickly: What changed? Which systems are affected? What should we check next? Finding those answers often means switching between monitoring tools, infrastructure consoles, tickets, and documentation.

We wanted to make that first step easier: ask a question from your phone and get an answer grounded in infrastructure evidence. That idea became INDRA, an infrastructure companion that brings investigation, incident updates, and carefully controlled actions into a mobile conversation.

What it does

INDRA's development deployment supports WhatsApp requests through AWS End User Messaging Social. An operator can ask about permitted infrastructure resources and receive an answer using connected tools. The WhatsApp flow has been exercised, while answer quality and reply formatting continue to be refined.

The project also includes monitoring-driven triage for Zabbix and Elastic alerts, bounded diagnostics, Jira incident handling, and recovery checks. These paths have different levels of verification: the development infrastructure exists, but some sources, credentials, and target inventories still need configuration and end-to-end validation.

Access is tied to an employee identity rather than a phone number alone. The current identity flow links an invite-only Cognito account to WhatsApp using a short-lived, single-use challenge. The current AWS-only operator is restricted to authorized AWS resources; that account does not gain access to VMware, firewall, or other infrastructure tools.

Investigation is primarily read-only, but the project now includes narrow, human-approved lab actions. A separate Ansible path supports an approved restart of one test service. The AWS operator has a separate, passkey-protected EC2 reboot approval path restricted to one allowlisted lab instance. These are bounded capabilities, not general autonomous remediation.

How we built it

We began with a Python foundation using LangGraph for bounded agent reasoning, A2A for agent communication, and MCP for controlled access to tools and inference. That foundation includes PostgreSQL persistence, a transactional dispatch outbox, and Temporal workers with restart and replay tests.

The active AWS development architecture uses Amazon Bedrock AgentCore and Amazon Nova 2 Lite for its Orchestrator and InfrastructureAgent. Application code validates handoffs between agents, while Gateway IAM and Cedar policies constrain tool access. The newer AWS-only identity route uses a separate agent Lambda with its own restricted AWS tool set.

The phone channel combines End User Messaging Social, SNS, SQS, and Lambda. Deterministic workers handle routing, duplicate detection, delivery state, and retries. DynamoDB stores messaging, incident, identity, and approval records; Secrets Manager keeps credentials outside model prompts and chat messages.

For critical AWS changes, we implemented immutable proposals and WebAuthn passkey verification. Approval is bound to the exact employee, resource, action, and policy version. A separate executor rechecks authorization before dispatching an allowed operation.

Challenges we faced

The biggest challenge was separating a useful AI suggestion from permission to act. Model output cannot authorize access, select arbitrary destinations, or approve infrastructure changes. We kept identity, authorization, routing, and execution decisions in deterministic services outside the reasoning loop.

Agent handoffs were another practical challenge. Nova did not consistently emit the expected inline tool events, so we added schema validation and bounded application routing rather than relying on model text to drive execution directly.

Messaging also taught us to distinguish acceptance from completion. A provider accepting a message does not prove delivery, and an infrastructure API accepting a reboot does not prove recovery. We track these states separately and hold uncertain execution outcomes for reconciliation instead of blindly retrying a change.

What we learned

We learned that trustworthy infrastructure assistance depends on clear boundaries and verifiable state. Agents can interpret evidence and propose next steps, while services enforce who can see a resource, approve an action, and confirm its outcome.

We also learned that one successful demonstration does not validate every integration. Read connectors, incoming alerts, human approvals, message delivery, and recovery checks each need their own evidence and tests.

What's next

Our next steps are to finish approved connector and target onboarding, resolve remaining integration and credential issues, improve answer quality, and expand end-to-end testing. We also need broader operational validation before making production-readiness claims.

RCS, backup recoverability assessment, broader network access, and a shared production administration experience remain future scope rather than demonstrated features.

Our goal remains simple: ask INDRA from your phone, understand what is happening, and take the next step with evidence and control.