DriveTech moved its entire AI layer off the application backend and onto Amazon Bedrock AgentCore – turning a founder-built prototype into a reproducible, multi-tenant platform ready for enterprise procurement.
01 – The situation
A demo that could not become a product
DriveTech builds a resilience and skill-improvement platform for organizations, aligning workforce capability with business objectives. The product spans three surfaces: a personal experience, an organizational dashboard, and what the team calls the Brain – the methodology and AI orchestration layer that connects them.
The platform began as a founder-led MVP. A personal resilience assessment ran on S3 and CloudFront, a Node.js backend ran on EC2 behind an Auto Scaling Group, and the AI layer was a set of direct model calls embedded in that same backend. It worked as a demonstration. It did not work as a foundation for enterprise sales.
Every model call, prompt construction, and conversation-history query shared CPU, memory, and scaling rules with the REST API. A single streaming coaching conversation could occupy a container for tens of seconds while ordinary API requests queued behind it. The two most recent production incidents were rate-limiting errors and slow AI responses – both symptoms of the same coupling. Scaling for AI load meant overprovisioning for API load, and the reverse.
Meanwhile the commercial target was healthcare and education, where prospects arrive with HIPAA and GDPR expectations already written into procurement – against a platform handling personal psychological and resilience data.
Where it started
- Console-provisioned infrastructure – nothing reproducible, new environments built by hand
- Environments that did not match – a third-party Postgres in dev, RDS in prod
- Secrets in plaintext
.envfiles, edited over SSH on the instances - No automated tests, no rollback path beyond a branch merge
- No image scanning, no backup or restore policy, no restore ever tested
- Observability was budget alerts – errors found by tailing Docker logs over SSH
- Resources split across two regions for no architectural reason
What was needed
- Separate AI from API so each workload scales on its own terms
- Governable AI behavior – prompts versioned, reviewable, auditable in production
- Every environment from code, with no manual console steps
- Enterprise security posture – no long-lived credentials, managed secrets, tested backups, tenant isolation
- Headroom to grow from hundreds of users toward hundreds of thousands without a rewrite
02 – The build
The backend became a gateway. The reasoning moved to AgentCore.
Develeap worked with DriveTech to rebuild the platform around one clear separation. Prompt construction, memory management, summarization, retrieval, and model invocation all left the application code. What remained in the backend was authentication, validation, routing, and CRUD – a thin authenticated pass-through to the agents.
Four purpose-built agents
Rather than one general-purpose assistant, the intelligence layer is four independently deployable agents, each with a single responsibility and its own release cadence. Each is a Python 3.12 service cross-compiled to linux/arm64, running as a container on the AgentCore runtime.
Drive Coach
Enriches every message with the person’s battery profile, assessment history, plan summary, stated preferences, facts recalled from past sessions, and retrieved methodology context – then streams the response back token by token.
Haiku 4.5 · 800 max tokens · 1k thinking budgetBattery Analyzer
Structured analysis of a completed assessment across four dimensions – physical, mental, emotional, and meaning – returning validated JSON per language.
Sonnet 4.5 · strict schema validationIntervention
Generates personalized resilience recommendations per dimension, with structure validation guaranteeing every category is present before the response reaches the user.
Sonnet 4.5 · no retrieval by designOrg Intelligence
Company-level resilience analytics for administrators, over aggregated and anonymized data – never individual records.
Sonnet 4.5 · org-scoped accessAll four import a shared library covering configuration, Cognito JWT validation, memory, knowledge retrieval, and prompt fetching – so a fix to auth or memory ships once, not four times.
The reasoning layer
- Amazon Bedrock provides the models. Analysis and recommendation agents run Claude Sonnet 4.5 where reasoning quality drives output quality; the high-volume conversational path runs Claude Haiku 4.5 with an explicit token budget and extended-thinking allowance. Model selection is a Terraform variable, not a code change.
- Bedrock Prompt Management holds every system prompt as a versioned, governed resource. Refining the coaching persona no longer requires a code release.
- AgentCore Memory runs three strategies in parallel – semantic fact extraction, per-session summarization, and user preference – replacing a proposed six-table hand-rolled memory schema.
- Bedrock Knowledge Bases ground responses in DriveTech’s own methodology documents, using Amazon S3 Vectors with Titan Text Embeddings v2. Choosing S3 Vectors over a provisioned serverless search cluster removed roughly $700/month of fixed cost from the AI layer before a single user was served.
Reliability as a design constraint
Every agent degrades gracefully. Knowledge-base retrieval, memory reads and writes, and auth enrichment are all non-fatal – if a dependency is slow or unavailable, the agent answers with less context rather than failing the user. Every exception is caught at the invocation boundary and returned as a structured error; an agent never raises into the runtime. Conversation history is read from PostgreSQL rather than held in process, so agents hold no state and any instance can serve any turn.
Infrastructure as code, end to end
The platform is defined in 24 reusable Terraform modules, deployed across three environments through six ordered layers. Each layer consumes the previous layer’s outputs through remote state, so the deployment order below is a real dependency chain, not a convention.
Dev runs single-AZ and cost-optimized. Prod runs across two Availability Zones on an Aurora PostgreSQL cluster with deletion protection, 30-day backup retention, AWS WAF on CloudFront, and ECS Fargate autoscaling from two tasks to eight.
Security, changed in kind
- GitHub Actions authenticates to AWS through OIDC – no long-lived AWS keys exist anywhere in the delivery pipeline.
- Secrets moved from
.envfiles on instances into AWS Secrets Manager and SSM Parameter Store. - Authentication moved to Amazon Cognito – email and password, one-time passcodes, and Google federation – with custom Lambdas for branded emails and JWT audience shaping.
- Agents are instrumented with the AWS Distro for OpenTelemetry, deliberately configured not to capture message content, keeping personal conversational data out of the observability pipeline.
- CI detects which agents changed, builds and pushes only those images to ECR, and patches the corresponding AgentCore runtime. Dev deploys on merge; production is manual dispatch only.
03 – The result
Outcomes & impact
A long streaming coaching session no longer blocks REST traffic. The two run on separate compute with separate scaling rules, removing the root cause behind the platform’s rate-limiting and latency incidents.
Prompt construction, memory, summarization, retrieval, and model invocation all left the application code. The chat handler became a thin authenticated pass-through.
Versioned prompts in Bedrock Prompt Management let the methodology owner iterate on coaching behavior with review and rollback, independent of engineering releases.
Manual console provisioning is gone. Dev and prod are the same 24 modules with different parameters, closing the environment-drift gap that made releases unpredictable.
No static cloud credentials, managed secrets, an encrypted multi-AZ database with defined retention, WAF at the edge, tenant-scoped access, and telemetry that excludes conversation content.
Selecting S3 Vectors over a provisioned vector search cluster avoided roughly $700 per month in standing cost, keeping AI-layer spend proportional to actual usage.
04 – The collaboration
Working with AWS and Develeap
DriveTech arrived with a working product idea and a prototype built under time pressure by a two-developer team with no platform specialist. The gap was not ambition – it was the distance between a demo and something an enterprise buyer will sign for.
Amazon Bedrock AgentCore closed most of that distance by absorbing the parts small teams usually build badly: agent runtime, cross-session memory, retrieval, and prompt governance as managed capabilities rather than bespoke code. That let two developers ship an agentic architecture that would otherwise have required a dedicated ML platform group.
Develeap contributed the architecture and the delivery foundation underneath it – the Terraform module library, the layered environment model, OIDC-based pipelines, secrets and observability – along with the design review that removed unnecessary components before they were built. Two services proposed in the original plan, SQS and DynamoDB, were challenged and eliminated rather than implemented.
The result is a platform a two-person team can operate, and a larger team can inherit.
05 – What’s next
Next steps
- Broadening the organizational intelligence surface, including AI-generated charts and statistical views for administrators
- Deepening the coaching journey – commitment capture inside conversations, and progression signals across sessions
- Adding predictive alerting as a two-tier design: deterministic rules for the decision, AI for advisory context
- Formalizing the compliance story for healthcare and education procurement, building on the tenant isolation and data-handling controls already in place
- Load-testing beyond the current provisioned envelope, on the path toward the long-term user target
The architecture that took DriveTech from prototype to enterprise-ready is the same one meant to carry it to its next order of magnitude.
