Dustin Mihalik

Dustin Mihalik is a software engineer in Austin, Texas, building AI platforms at Indeed. He emphasizes resilient systems, humane AI experiences, and helping engineers grow. His work on conversational job search addresses a concrete problem: an interface can show useful results while leaving the assistant unable to understand them or continue investigating. (Personal website)

His AI-platform responsibilities include guardrails, gateways, and compliance. At the time of his MCP-apps talk, his team had worked on integrations for Claude, ChatGPT, and Career Scout, Indeed’s job-seeker agent. Those integrations connect platform requirements with practical questions: can a job seeker open a listing, compare opportunities, and ask a follow-up about the position they selected? Mihalik’s approach starts with the information the assistant needs to perform those tasks, then considers how to display it.

Developer tools, from components to model evaluation

Mihalik’s open-source projects address several parts of the development process. His React Storybook Docgen Addon brings generated component documentation into Storybook, placing information about components in the environment where developers work with them. The module is no longer actively developed.

LLMStat applies a tooling approach to prompt evaluation. The experimental command-line project generates language-model responses, evaluates prompts against datasets, and compares runs. It uses JSON configuration and output and delegates assertions to Promptfoo. Its ability to evaluate saved responses separates generation from evaluation: developers can revisit an existing run without generating every answer again. The project describes itself as not production-ready.

ME-MCP makes professional information and communication accessible through agent tools. Designed for Cloudflare Workers, the lightweight Streamable HTTP MCP server exposes résumé information and lets agents send messages through Discord webhooks. It provides explicit operations for retrieving information and contacting the configured server owner.

Keeping the assistant useful behind the interface

In Indeed’s job-search integrations, widgets gave the team control over application buttons, highlighted details, and a modal containing the full job description. This addressed the difficulty of getting text-based assistants to consistently include usable job links. It also created a second challenge: the assistant needed to understand both what the widget displayed and what the user did with it. Mihalik’s approach to MCP-app design addresses three related concerns:

• Displayed records: Data shown to the user must also reach the model. A widget that independently loads records through an API can leave the assistant unable to explain the first result or compare the companies on screen. Returning structured content for the model alongside a resource URI for the widget’s HTML keeps the two representations aligned.
• User selections: Opening a job-details modal identifies a position to the interface without necessarily identifying it to the assistant. Passing the selected job and its details into model context enables a follow-up request to summarize that position or write a cover letter. Mihalik describes using the MCP-apps context-update method for these interactions.
• Interface behavior: Tool descriptions should explain when results are already visible as UI components. Otherwise, the assistant may repeat the widget’s contents in a long text response. That information helps it add useful commentary instead of duplicating the display.

Letting search finish before rendering

Mihalik argues for separating search from rendering, explicitly crediting the principle to OpenAI’s Apps SDK documentation. His team observed that attaching a carousel to search could encourage Claude to stop after one call. Repeated calls would also produce multiple carousels, making it harder to present a considered shortlist.

A job seeker willing to relocate, seeking higher pay, and excluding particular industries needs the assistant to search across cities, compare opportunities, and filter candidates before displaying them. Indeed’s team separated a data-only search tool from a rendering tool that accepted selected job IDs. The assistant could then explore multiple result sets and show only its chosen jobs. Rendering-tool descriptions explained where to obtain the data and which input format to use.

Mihalik favors small composable tools: distinct ways to search, display a list, or highlight one job. Keeping those operations narrow gives the assistant flexibility without overloading individual tool descriptions. He also proposes allowing rendering tools to accept a reason a position fits or a passage worth highlighting, carrying the assistant’s judgment into the widget alongside the job record. These are proposed extensions, rather than claims about shipped features.