Every tool below has shipped in production.
This isn't a wishlist of trendy frameworks. Items tagged with a case study link are things we've actually used on a named, shipped engagement — click through to see it in context.
6
Technology categories
27
Tools & services in active use
16/27
Directly tied to a named case study
4
Production systems shipped
Principles behind every stack decision.
Boring where it counts
Core data infrastructure runs on proven, unglamorous tools — Postgres, S3, standard cloud primitives — so engineering effort goes into the agent and AI layer, not into explaining a database outage.
The right model for the job
We pick between Claude, OpenAI, and Bedrock-hosted models based on the task — latency, cost, vision vs. text, instruction-following needs — not brand loyalty to one provider.
Standard APIs over lock-in
Every system we ship is built on documented, portable APIs and mainstream cloud infrastructure, so you're never structurally dependent on us to keep it running.
Guardrails are part of the stack
Logging, fallback paths, and human-review hooks are chosen alongside the model and shipped with the first release — not retrofitted after something breaks in production.
Grouped by what each layer does.
LLMs & AI platforms
The models doing the reasoning, classification, and conversation.
Agent orchestration
Frameworks for multi-step, tool-using agent workflows.
- LangGraph
- CrewAI
Data & retrieval
Where structured data, vectors, and operational records live.
Application & web
The product layer end users and internal teams interact with.
Cloud & infrastructure
Where these systems actually run in production.
Integrations & tooling
Third-party services wired into the systems above.
Blue tag = used on a real, shipped case study — click through to see it in context.
Decisions we get asked about.
Claude vs. OpenAI — how do you choose?
We default to Claude for tasks that need careful instruction-following or vision classification — the Stupell defect classifier is a Claude vision model for exactly this reason. We reach for OpenAI when a client's existing pipeline is already built around it. Both APIs are fully supported either way.
Pinecone vs. pgvector — when does a dedicated vector database earn its place?
If a project already runs Postgres, pgvector often removes the need for a separate vector database entirely. Pinecone earns its place when retrieval scale or query latency genuinely need a dedicated service — we don't add infrastructure a project doesn't need yet.
LangGraph vs. CrewAI — which agent framework fits?
LangGraph fits workflows with explicit state and branching logic that need to be predictable and debuggable. CrewAI fits role-based, multi-agent setups where several specialized agents divide a task. We choose based on how deterministic the workflow needs to be, not by default.
No-code automation vs. a custom pipeline — when do you rebuild it?
Zapier-style automations are fine until the decision logic outgrows simple triggers. That's the point where we replace them with a custom pipeline with an LLM in the decisioning layer — as in the Vendor Compliance Automation case study, which replaced 24+ fragile Zapier automations with one AWS Lambda pipeline.
Common questions about how we build.
What LLMs does Eveonix build with?
Primarily Anthropic's Claude API and OpenAI, plus AWS Bedrock-hosted models (including Claude) and Amazon Nova Sonic for voice. Model choice depends on the task, not a fixed default.
Can you build on our existing cloud account and infrastructure?
Yes. Most engagements connect into a client's existing AWS, Postgres, or Supabase setup rather than standing up parallel infrastructure. Eveonix is also a registered AWS Partner and AWS Marketplace seller.
Do you build with open-source tools or proprietary platforms?
Almost entirely open-source frameworks (LangGraph, CrewAI, OpenCV) and standard vendor APIs (Claude, OpenAI, AWS) rather than closed no-code platforms — so there's no proprietary lock-in.
Who owns the code and prompts after launch?
You do. Every engagement ships as code and configuration in your own repository and cloud account, not a black-box hosted service you have to keep renting access to.
Do you build production RAG systems with PostgreSQL and pgvector?
Yes — pgvector is one of our default retrieval layers when a project already runs Postgres, covering ingestion, chunking, hybrid search, and citations without standing up a separate vector database. See our guide on building a production RAG system with PostgreSQL and pgvector for the full architecture.
Can you build AI agents with LangGraph?
Yes. LangGraph is our default framework for agent workflows that need explicit state, branching, and debuggable execution — the kind of production-ready AI agents covered in our LangGraph guide.
Do you build AI voice agents with Amazon Connect and AWS Bedrock?
Yes — this is a named part of our stack, not a one-off. We've shipped a production AI voice intake agent on Amazon Connect and Bedrock, and wrote up the architecture in our Amazon Connect + Bedrock voice agent guide.
Do you design human-in-the-loop approval steps into AI agents?
Yes. Confidence thresholds, tiered escalation, and SLA timeouts that decide when an agent acts alone versus handing off to a person are built in from the first release, not retrofitted later — see our guide on human-in-the-loop workflow design patterns.
Already have a stack in mind?
Most engagements connect with what you already run — existing apps, APIs, data sources, and internal tools. Tell us what you're working with.