Production Agent on Claude Without LangChain and RAG: 712-Line Architecture for an Interior Design Studio

An independent developer published a detailed breakdown of a production agent architecture on Claude, created for a small interior design studio. The entire system fits in a single main.py file with 712 lines of code and two system prompts — no LangChain, no RAG frameworks, and no vector databases.

What components make up the agent

The roles of two Claude models are clearly divided by task type. The chat interface runs on Claude Haiku 4.5: the model responds quickly to client questions, clarifies requests, and maintains dialogue. Claude Sonnet 4.6 handles design concept generation: it transforms client wishes into a structured interior description. Photos for concept visualization are sourced from the Pexels library — this is significantly cheaper and faster than generating images through DALL-E.

Key solution parameters:

• Claude Haiku 4.5 — client dialogue: fast and economical
• Claude Sonnet 4.6 — generation of structured design concepts
• Pexels API — photo selection instead of DALL-E
• One main.py file, 712 lines of code, two system prompts
• No orchestrators, vector databases, or frameworks on top of the API

This architectural choice is not accidental. For a studio with a limited budget and small client flow, a full-scale RAG stack is over-engineering. Haiku is cheaper for dialogue; Sonnet is only engaged where structured creative generation is needed. There's no point in solving a scalability problem that doesn't yet exist.

What pitfalls were encountered?

The first non-obvious issue is the prompt caching threshold for Claude Haiku 4.5. Context caching only activates above 4096 tokens. If the system prompt is shorter than this threshold, each request is treated as new — caching doesn't work at all. Under high load, this noticeably impacts both request cost and response latency.

The second subtlety is Sonnet 4.6's behavior with structured output. The model sometimes wraps the JSON response in an extra text block instead of returning clean JSON. Standard `json.loads()` fails with an error in such cases. The author tried several parsing strategies and settled on a simple wrapper with fallback logic — it's more reliable than extracting JSON with regular expressions.

"This isn't a guide from an expert — more like a journal of decisions.

I tried to honestly explain why I made each choice," the developer explains.

The logic of model division deserves special attention. The author tried processing everything with a single model but quickly realized: Haiku should be used where speed and cost matter, and Sonnet where you need quality structured output. Attempting to save money by running concept generation through Haiku produced noticeably worse results.

Where will this approach break?

The developer honestly outlines the boundaries of their solution. One 712-line file works fine for an MVP and a small studio, but scaling will create problems:

• As the client base grows, dialogue history storage becomes necessary — without a vector database or external storage, it's unavoidable
• If the studio wants to accept and analyze photos from clients, a multimodal pipeline will be needed
• Logging agent activity to a file doesn't work with multiple concurrent users and real load
• As prompts grow more complex, they become harder to test and version in a single file

The main conclusion the author draws: for a task with narrow and clear boundaries, "without RAG" is not a lazy solution but a deliberate architectural choice. Frameworks solve real scaling problems but create new ones: complexity, dependencies, infrastructure overhead. If the problem hasn't emerged yet, don't create it for the sake of a tool.

What this means

The publication shows: Claude API is sufficient for a production agent without supporting frameworks, if the task is specific enough. For developers beginning to build agents on Claude, this is an honest breakdown of real pitfalls — the cache threshold for Haiku 4.5, JSON parsing for Sonnet 4.6, thoughtful task distribution between models of different tiers.