Agentic Software Engineer Skills Challenge

The Scenario

You are a full-stack engineer at arrivia, a global travel loyalty technology company that powers white-label booking platforms for banks, financial institutions, and membership organizations worldwide.

arrivia's platform handles 30,000+ itineraries across 700 airlines, 1M+ hotels, and 30,000 rental car locations. Partners integrate arrivia's booking engine, loyalty currency, and marketing tools into their own branded experiences — meaning arrivia operates a multi-tenant, white-label architecture where partner-specific configuration, branding, and pricing rules must coexist on a shared platform.

Your team has been tasked with building a new internal service: an Agentic Travel Recommendations API. This service will allow AI agents (powered by tools like Claude Code and MCP integrations) to query a member's travel history, loyalty tier, and partner-specific rules to generate personalized travel recommendations. The goal is to power a new 'AI Concierge' feature that partner brands can embed in their booking portals.

Here is what you know:

• The member data service already exists as a RESTful API (you can mock it). It returns: member ID, loyalty tier (Silver/Gold/Platinum), travel history (last 5 bookings with destination, dates, and booking type), and partner ID.
• Partner-specific rules vary: some partners cap recommendations at 3 per session; others allow unlimited. Some partners exclude cruise offers entirely. These rules are stored in a partner configuration service (you can mock this too).
• The AI agent will call your service via MCP — your API must expose endpoints that an AI agent can discover and invoke through a Model Context Protocol server.
• Read the provided constraints carefully — they define what you can and cannot change.

Constraints

• Existing infrastructure only: Your service must work within arrivia's current cloud and technology stack (AWS/Azure services, containerized deployment). Do not propose a new infrastructure layer or third-party platform that arrivia does not already use.
• Partner configuration is read-only: You cannot modify the partner configuration service. You can only read from it. Your service must respect whatever rules the partner config returns, even if they seem suboptimal.
• Four-week first step: Scope your implementation to what a single engineer could realistically ship in four weeks. Your README should identify what ships first vs. what comes later.
• On-call ownership: You and your team will own this service in production. Whatever you build, you are on call for at 2am. Design accordingly.