Designing Amy AI: turning a non-sycophantic backend into a calm teen-facing product

Amy AI was different from most AI products I had worked on because the product promise was behavioral, not cosmetic. The system is built to validate emotions while challenging cognitive distortions, which means the interface cannot feel like a generic agreeable chatbot.

My role covered the full product experience: designing the UI/UX, connecting it to backend APIs, and making the whole thing feel smooth and emotionally grounded for teen users.

The Backend Changed the Design Brief

Amy's backend architecture was already serious.

• FastAPI handled core APIs and system orchestration
• OpenRouter routed across providers like GPT-4o-mini, DeepSeek-V3, and Claude for specific safety cases
• Redis tracked session state, rate limits, and validation state
• PostgreSQL stored users, sessions, messages, and crisis events
• Qdrant was planned for memory and semantic retrieval

This meant I was not designing a static chat shell. I was designing a product surface over a multi-service decision system.

Designing for Anti-Sycophancy

The core IP in Amy is the anti-sycophancy pipeline. The system monitors agreement levels and injects productive friction when the rolling agreement ratio becomes too high.

That changed how I approached UX.

• The product had to feel warm without feeling submissive
• The chat interface had to support challenge and nuance without feeling confrontational
• Error states and transitions had to preserve trust, because the product is dealing with emotionally sensitive moments

A teen-facing AI product cannot rely on visual polish alone. The interaction model has to reinforce the behavior model underneath it.

API Integration as Product Work

A lot of the important work was not visible in screenshots.

I integrated frontend flows with backend APIs so the experience stayed coherent across onboarding, authentication-adjacent flows, chat requests, health states, and failure cases. The hard part was making backend complexity feel invisible.

Instead of exposing technical system behavior directly, I focused on:

1. Readable request states so users understood when the product was processing
2. Calmer transitions so the interface never felt jumpy or over-animated
3. Better error handling so failures felt human and recoverable rather than system-heavy

What I Learned

Amy reinforced a principle I now trust more strongly: advanced AI products need stronger product design, not weaker design. The more complex the orchestration underneath, the more the interface has to communicate restraint, trust, and emotional clarity.

For Amy, smooth UX was not a finishing layer. It was part of the safety model.