So I built Tesseric to analyze AWS architectures using Claude via Bedrock. You describe your system, it returns structured findings with security risks and remediation steps. Standard stuff.
Then something weird happened.
I was testing it with a 3-tier web app description - ALB in front, EC2 instances in the middle, RDS at the bottom. The analysis came back with findings like "EC2 instances in single AZ" and "RDS encryption disabled." Good. But I kept scrolling between findings thinking "wait, which layer was that again?"
I was mentally reconstructing the architecture diagram from the text I'd just submitted.
That felt backward. The AI clearly understood my architecture - it was extracting service names, understanding relationships, identifying which components had issues. So why was I stuck staring at a list?
What if I could see the architecture? Not just read about it.
The First Graph: Knowledge Accumulation
Before I get to the fun part, let me rewind to where this started.
After running a few dozen test reviews, I noticed patterns. Every finding mentioned AWS services. Reviews kept touching the same services. I started asking questions like "if EC2 has issues, does RDS usually have problems too?" or "which services appear together in high-severity findings?"
I was doing graph traversal in my head on flat JSON responses.
That's when I added Neo4j. Not for the individual reviews - for cross-analysis pattern detection. The schema is simple:
(:Analysis)-[:HAS_FINDING]->(:Finding)-[:INVOLVES_SERVICE]->(:AWSService)
The magic trick is MERGE. In SQL, if EC2 appears in 50 analyses, you have 50 rows. In Neo4j, EC2 becomes one node, and every analysis just adds another relationship to it.
Query for service co-occurrence:
MATCH (s1:AWSService)-[r:CO_OCCURS_WITH]->(s2:AWSService)
RETURN s1.name, s2.name, r.count
ORDER BY r.count DESC
Result: "EC2 and RDS co-occur in 23 analyses. RDS and S3 in 17."
That pattern only emerges from accumulated data. After a few dozen reviews, the graph starts telling you things about architecture patterns you didn't explicitly ask for.
Graph writes happen async with asyncio.create_task() so the core analysis stays fast. If Neo4j is down, the user never knows. Graceful degradation, not cascading failures.
But here's where it got interesting.
The Second Graph: Your Architecture, Visualized
Once I had Neo4j working, I kept thinking "this is cool for meta-analysis, but users don't care about cross-analysis patterns for their first review."
Then it hit me: the AI is already extracting AWS services. It knows EC2 connects to RDS. It knows the ALB sits in front. That's topology information, not just a list.
What if I asked Claude to return the actual architecture structure?
I updated the Bedrock prompt:
"Extract the architecture topology: which services exist, how they connect, what layer they're in. Return as a structured graph."
It worked. First try.
Submit "ALB in front of two EC2 instances connecting to an RDS database" and Claude returns:
{
"services": [
{"id": "alb-1", "type": "ALB", "layer": "presentation"},
{"id": "ec2-1", "type": "EC2", "layer": "application"},
{"id": "rds-1", "type": "RDS", "layer": "data"}
],
"connections": [
{"from": "alb-1", "to": "ec2-1"},
{"from": "ec2-1", "to": "rds-1"}
]
}
Now I could draw it. React-Flow + dagre for auto-layout. Color-code by layer (blue for frontend, green for backend, purple for data). Add borders based on severity (red if service has HIGH findings, orange for MEDIUM).
The result: you describe your architecture in text or upload a diagram, and Tesseric draws it back to you with visual problem indicators.
That's the moment users go "oh shit, it actually understood."
Why This Matters (The Graph Thinking Part)
Here's what I'm learning about graphs: they change how you think about your data.
In SQL, you model entities. In graphs, you model relationships. That shift completely changes what questions feel natural to ask.
With Neo4j knowledge graph, I can ask "show me all analyses where EC2 and RDS both appeared in HIGH severity findings" and get a visual cluster showing that risk pattern across time.
With architecture topology, I can click an EC2 node and instantly see which findings affect it. Or click a finding card and watch the affected services highlight on the diagram. Bidirectional linking that feels spatial, not tabular.
The architecture visualization isn't just prettier than a list - it's spatially encoded. You see the ALB at the top, EC2 in the middle, RDS at the bottom, and your brain instantly knows "that's a 3-tier app." You don't have to read it, you just know.
When three findings all point to the same EC2 node with a red border, you see the critical risk cluster without reading a single word.
Humans are visual creatures. We're ridiculously good at pattern recognition when information is laid out spatially. A graph lets you leverage that.
The Stack
Backend: FastAPI + Python 3.11, AWS Bedrock (Claude 3.5 Haiku/Sonnet), Neo4j AuraDB
Frontend: Next.js 14, TypeScript, React-Flow, dagre for auto-layout
Cost: ~$0.011 per text review, ~$0.028 per image analysis. Neo4j free tier. Railway + Vercel hosting ~$5/month. At 100 reviews/day, that's $33/month in AI costs.
React-Flow is genuinely well-designed. Custom nodes, edges, built-in minimap. Got a working graph in a few hours. Dagre handles hierarchical layout for architecture topology, force-directed for knowledge graph.
The Bigger Realization
I thought I was building a knowledge graph to analyze trends across reviews. That was useful.
But the architecture topology visualization - showing users their own system drawn back to them with problem indicators - that's the feature that makes people go "whoa."
It's the difference between "here's a list of issues" and "here's your architecture, and here's exactly where the problems are."
Spatial thinking beats text lists. Graphs give you that spatial encoding almost for free.
If you're building something with interconnected entities - services, users, dependencies, networks - you're probably fighting SQL when a graph would make those queries trivial.
And if you're analyzing architectures or anything with structure? Don't just return text. Draw it. Show it. Let people see the shape of the problem.
That's when AI stops feeling like a chatbot and starts feeling like it actually understands.
Try It
Live demo: tesseric.ca
Describe your AWS architecture or upload a diagram. Watch it draw your system back to you with visual problem indicators. Then explore the knowledge graph to see how services and findings connect across analyses.
Built with AWS Bedrock, Neo4j AuraDB, FastAPI, Next.js, and React-Flow. Open source. Brutally honest feedback mode included.
Check out the code at github.com/iamarsh/tesseric
Top comments (0)