PlateForce
Designing an AI meal-planning system around constraints, not generic recommendations.
PlateForce explored AI meal planning as a constraint-satisfaction problem rather than a generic chatbot experience. We built three agentic recommendation workflows using Agentforce, Java, and REST APIs, supported 5+ dietary preferences, generated 50+ personalized recommendations, and placed second in the Salesforce Agentforce Hackathon.

TL;DR
PlateForce explored AI meal planning as a constraint-satisfaction problem rather than a generic chatbot experience. We built three agentic recommendation workflows using Agentforce, Java, and REST APIs, supported 5+ dietary preferences, generated 50+ personalized recommendations, and placed second in the Salesforce Agentforce Hackathon.
Useful meal planning is a constraint problem, not just a creativity problem.
Meal recommendation sounds like a simple AI use case: tell the system what you want to eat and generate a recipe. In practice, useful meal planning is less of a creativity problem and more of a constraint problem. A recommendation can sound perfect while still being unusable if it ignores someone's dietary restrictions, available ingredients, preferences, or nutritional needs.
Our team built PlateForce around that distinction. Rather than treating the product as an open-ended chatbot, we designed the experience around structured user context.
The product hypothesis
Our hypothesis was that AI meal recommendations would become more useful when the system could reason from explicit constraints rather than relying on a single open-ended prompt. This pushed us away from treating the conversational interface itself as the product because the important logic happens before a response is generated.
The system needs to understand which information should guide the recommendation and how that information should be structured.
Turning preferences into usable context
PlateForce supported 5+ dietary preferences and generated 50+ personalized meal recommendations. We designed the experience so that user preferences could influence the recommendation workflow without requiring users to restate every constraint with each request.
That distinction matters in AI products because a good user experience should not force someone to become an expert prompt engineer. The product should do the work of translating user context into the structured information the model needs.
Prototype screens
These screens show the existing PlateForce prototype artifacts while the written case study focuses on the updated product narrative.

Designing multiple AI workflows
We developed three recommendation workflows instead of depending on one generalized prompt. Separating the workflows gave us more control over how context was handled and made the system easier to reason about.
The underlying principle was that different user intents can look similar in the interface while requiring different reasoning paths underneath. Agentic systems can appear flexible while becoming difficult to predict, so separating workflows allowed us to define more clearly what each path needed and what type of output it should produce.
Grounding the output
One of the central risks in an AI recommendation product is plausibility. A model can produce something that sounds reasonable without actually satisfying the user's constraints. We therefore incorporated structured retrieval and grounding into the workflow instead of treating model generation as the entire product.
The system architecture included a Java backend and REST API integrations that supported the agent workflow. For me, this reinforced a key AI PM lesson: model capability is only one component of product quality. Context, orchestration, retrieval, validation, and interface design determine whether that capability becomes useful.
Designing for failure
If I continued developing PlateForce, I would spend more time defining failure behavior. I would want to understand what should happen when constraints conflict, when there is not enough information, when the agent should ask a follow-up question instead of making an assumption, and which constraints should always be treated as non-negotiable.
Those questions are especially important for dietary preferences because some inputs represent taste while others may represent strict restrictions. The product should not treat those categories as equivalent.
Measuring the experience
I would not evaluate PlateForce primarily on the number of recommendations generated because a recommendation only creates value if the user would realistically consider using it. I would measure recommendation acceptance, percentage of outputs satisfying all hard constraints, regeneration rate, reason for rejection, user edits after recommendation, repeated use, latency, and workflow failure rate.
One metric I would pay particular attention to is constraint failure rate. A creative recommendation that violates an important user constraint is worse than a less novel recommendation that is actually usable.
Result
PlateForce placed second in the Salesforce Agentforce Hackathon. The project gave me experience thinking about AI beyond prompting and helped me understand how product architecture shapes the user experience.
What I learned
The biggest lesson was that AI does not eliminate product structure. It makes product structure more important. Users should not need to know how the model works, which context it receives, or which workflow is being invoked, but the product team needs to make those decisions deliberately.
PlateForce taught me to ask a different question when evaluating AI features. Instead of only asking, “Can the model do this?” I now ask, “What system needs to exist around the model for users to trust the result?”
Predicting Movie Success
Using data to explore what drives film performance.
VIEW PROJECT →