Thanks for your time. This assignment looks like real work at TextYess, at a smaller scale.
Deliverable: one Git repository with a README.md at the root. Nothing else.
E-commerce brands send marketing emails every week. Every email must look and sound like the brand: its colors, its fonts, its logo, its tone. Today somebody rebuilds this by hand for every email.
Your job: build an agent that learns a brand once, then writes on-brand emails from a prompt.
- Learn the brand. The user gives a website URL, or documents, or both. The agent reads them and builds a design system: a structured description of how the brand looks and sounds.
- Write emails. The user chats with the agent. The agent writes an email that obeys the design system. The user sees the email while the agent builds it.
The user enters a website URL. The user can also upload documents: a brand guideline PDF, images, or a past email as HTML. The agent extracts what it needs and produces the design system.
Must have:
- A website URL as input.
- At least one document type as input.
- The design system stored as a structured artifact. You define the schema. The email step reads it.
- A view of the design system, so the user can see what the agent understood.
Left: the chat with the agent. Right: the email preview.
Example: the user types "Generate an email for a Black Friday event with a 20% discount." The email appears on the right, in the brand's design system.
Must have:
- Streaming. The agent streams to the UI. The email appears in real time, part by part, while the agent reasons and builds it. No spinner that ends with a finished email.
- Edits stream too. A follow-up message changes the current email. "Make it 30% and add urgency" must not start from a blank page. The user watches the change land in the preview.
- Reasoning. For each part of the email, the user can see why the agent made it that way: why this subject line, why this color, why this CTA. Show it in the UI, not only in logs.
- The email is real HTML that a person can send. Email-client-safe HTML (tables, inline CSS) or not, your call. Say why in the README.
The README is the main deliverable. We read it before we run anything. Cover these sections, in this order:
- How to run it. One command if possible. Which API keys we need.
- Product. The two screens, with screenshots or a short recording. The decisions you took, and why. What you cut.
- Architecture. The data model: the design system schema, the email, the chat session. The backend. How the UI receives updates.
- Agent. The steps, the tools, the prompts. How streaming and reasoning reach the UI. Which model for which step, and why. The cost of one design system and of one email. What happens when a step fails.
- Evaluation plan. Designed, not implemented. See the next section.
- Next. Two more weeks: what you build first, in priority order.
Target: a README we can read in 15 minutes.
Do not implement it. Write about one page:
- What "good" means. Obeys the design system. Obeys the prompt. Renders. Reads well. Pick what to measure. For each metric, say how you compute it: a deterministic check, a model judge, a human, or a mix.
- Test set. At least 10 cases across brands, prompts, and follow-up edits. Include hard cases: a prompt that conflicts with the brand, a website with almost no information, a language other than English, a dark theme.
- Gold signal. For each case type, what you compare against.
- Trust. How you know that the evaluation itself is right. For example, judge calibration against human labels.
- Cost. What one full run of the evaluation costs.
Do not skip this. How you plan to measure tells us more than what you built.
- API keys on request: OpenAI, Anthropic, Google. Ask for others. Email us, we reply the same day.
- Nothing else. Pick public brand websites you like.
Show at least two brands with clearly different identities in the README. We will also run your project on a website of our choice.
- Any language, any framework, any model.
- AI coding assistants are mandatory. We use them every day. Use them with judgment. We want to see your reasoning in the commits and in the README, not only a clean repository.
- Do not over-build. No auth, no billing, no deployment. A small system that works beats a large system that half works.
- Report cost and time honestly.
- Do not commit API keys.
- Learning loop. The agent learns the user's style from use. When the user edits an email or asks for a change, the agent keeps the preference. The next email applies it without being asked.
- The user can correct the design system before the first email.
- The agent renders the email, looks at the screenshot, and fixes what is off-brand.
- A website and a PDF that disagree. Say which source wins, and why.
- Send a test email to a real inbox.
- Emails in the brand's language, not only English.
- Software engineering. The data model. The backend. How the pieces connect: API contracts, state, streaming. Code we can read.
- Agent architecture. How the harness is built: steps, tools, structured output, state across turns. How streaming and reasoning reach the UI. Which model, and why. Cost. What happens on failure.
- Evaluation design. Metrics that measure something real. Hard test cases. An honest plan to trust the judge.
- Product mindset. Do the two screens make sense? What do you show the user, and what do you hide? How do you show the reasoning without drowning the user? Which decisions did you take, and which did you cut?
We do not grade visual polish, CI, infrastructure, or framework versus raw SDK.
One Git repository, public or shared with @valdo99 and @luisbeqja. README.md at the root.
Email luisb@textyess.com, cc edvaldo@textyess.com. Five minutes of questions beat a wrong guess.
Good luck. We want to see how you think.