DevDay Recap, Part 3 of 4: From Agent Demos to Dependable Applications

An expense assistant needs policy and personal context

An employee wants to expense a webcam that exceeds the company’s recommended allowance but still has money left in their equipment budget. The opening example in this part of the DevDay recap describes an assistant that could distinguish those conditions. A message in a Slack budget-request channel triggers the assistant; retrieval supplies the expense policy, while a budget-tracking tool supplies the employee’s remaining balance. Policy plus individual state lets the assistant explain both the allowance and the employee’s options.

The recommendation is to start with bounded internal workflows and learn their failure modes before expanding their reach. Two responsibilities accompany the automation: - Check accuracy before critical use. Add human approval steps and establish what the assistant is likely to get right or wrong. - Treat free-form input as an action risk. User text that triggers automated work creates prompt-injection risk. Internal deployment provides a manageable starting point for learning these constraints.

The exchange closes with a lighter example of prompting changing behavior: a demonstration advertised six voices, then used a pirate-style prompt that the interviewer jokingly called a seventh mode. This was a prompted speaking style, without establishing a separate voice model.

MultiOn: owning browser actions beyond APIs

Div Garg introduces MultiOn, a web agent for automating browsing, with claimed capabilities including booking flights, purchasing Amazon items, and ordering dinner. He proposes a division of responsibility: OpenAI provides the conversational entry point, while a third party owns risky browser actions. MultiOn would reach beyond websites’ APIs by using users’ existing browser logins or cookies to interact with personal accounts.

In Garg’s proposed ChatGPT integration, a flight-booking request would launch a browser whose actions the user could watch. Saved prompts could support recurring tasks such as ordering a favorite meal, with MultiOn handling execution, identity, and payment. Garg says the company already has a ChatGPT plugin and plans a MultiOn GPT powered by its API, extending its effort to make the agent embeddable in other applications.

For browser automation, vision’s value depends on what the existing parser can do. After more than a month of early Vision API access, Garg estimates that it was especially useful on roughly 5% of the websites tried, principally image-heavy ones. For about 95%, he thought OCR would suffice. These are informal estimates, without a stated sample size or evaluation protocol.

Garg says MultiOn’s parser can compress most websites to fewer than 3,000 tokens, reducing the need to use vision simply to avoid a bulky textual representation. His image-oriented example is a user who had MultiOn swipe on Tinder and obtained a match: a single anecdote illustrating the kind of visual task he has in mind.

The discussion’s present assessment is that vision adds modest value to a workflow already capable of doing much without it. Its marketplace forecast is more expansive: a guest imagines OpenAI challenging Apple’s App Store and conversational assistants eventually replacing much direct computer and phone use. These remain predictions about a possible future.

Bloop: measure usable context, not just window size

Louis Knight-Webb says he and his co-founder started Bloop to help engineers navigate large codebases, roughly three years before the interview. They initially trained relatively small models for natural-language code search. Those models remain one component of a larger pipeline, making context utilization a practical concern: can a new model actually use the information supplied to it?

Context utilization means successfully using information inside a prompt, beyond merely accepting its length. Knight-Webb argues that standard evaluations generally measure this poorly. When Claude 2 arrived with a 100,000-token context window, Bloop tested it directly: 1. Hide ten pieces of information in a prompt. 2. Increase prompt length through 1,000, 4,000, 8,000, and eventually 100,000 tokens. 3. Count how many pieces the model retrieves. 4. Repeat the experiment with GPT-4 to compare the degradation.

Knight-Webb reports that GPT-4’s retrieval fell from nine pieces at 1,000 tokens to one with a 32K context in this experiment. The result concerns Bloop’s particular retrieval task. Information placement, distractors, exact prompts, scoring, and repeated-trial counts are unspecified, so it does not establish a general accuracy curve.

The same test is his first priority for the newly announced 128K model. OpenAI evaluation staff had expressed confidence to him about improved long-context performance, but Bloop’s measurement was still pending. His approach makes usable capacity an evaluation question, rather than an assumption derived from the advertised window.

Other API features have different value to him: - Reproducibility has limited personal appeal. Knight-Webb likes variation and normally samples with some temperature. - JSON could simplify provider comparisons. A shared output format across commercial and open-source models would reduce provider-specific function-calling and parsing work.

Customer problems determine the useful autonomy

Bloop’s pipeline is described as GPT running in a large while loop with function calling—an arrangement that, one participant observes, clearly counted as an agent nine months earlier. Under another definition discussed, custom knowledge, custom instructions, and actions, the product already qualified. Yet customers with large codebases had not made an AutoGPT-style product an obvious next step. The architecture can qualify as an agent without making greater autonomy a customer need.

Reported users include people who read more code than they write: designers investigating the implications of an interaction and product managers examining a disputed developer time estimate. Bloop’s messaging had moved from prominently advertising model names toward explaining the problems it solves. The speaker connects that shift to its target customers and company stage, arguing that users have little reason to care about the agent label.

A safety discussion follows. One participant recounts speaking with PhD students studying adversarial fine-tuning, who reportedly found it very difficult, perhaps impossible, to prevent users from disabling safety features when fine-tuning is allowed. No study details or experimental conditions accompany the account; it remains a reported research concern rather than an established impossibility result.

A smooth autonomous ride leaves reliability questions

The setting becomes the subject: both participants are taking their first Waymo ride. One recalls collision notifications on three of roughly ten previous Cruise trips, typically when a vehicle ahead was trying to park. They suspect contact in one case but felt nothing in the other two; an intercom response followed the alerts. These were three reported alerts, not three confirmed crashes.

Driving conditions complicate the comparison. The same participant says nighttime Cruise trips felt fine, while a rush-hour trip involved markedly different routing and a long journey. Traffic management and neighborhood differences are offered as possible explanations for the contrast with the current smooth Waymo ride.

One participant marvels that everyday AI automation feels primitive beside the car carrying them. The other expects London’s narrower roads and mixed traffic to delay an equivalent experience. The exchange also raises the gap between a polished experience and visible failure modes: could an opaque driving system conceal problems that people encounter directly with GPT? The participant posing that comparison explicitly does not know how the driving pipelines are built.

Built-in retrieval still needs application evaluation

The next interview introduces Shreya Rajpal of Guardrails AI. It opens with the AI Engineers Summit’s 18-minute talks: Rajpal initially wondered whether that was enough time, but ultimately found it a useful bite size. The interviewer says the duration was optimized for YouTube.

Rajpal’s main DevDay interest is built-in retrieval. Her longstanding view is that retrieval does the difficult work: good retrieval gets an application much of the way to useful results, with generation contributing a smaller increment. She wants to see whether other commercial and open-source providers adopt the capability and how much retrieval engineering developers still need to do.

The interviewer argues that OpenAI has incorporated basic patterns and that advanced retrieval will still need tools such as LangChain and LlamaIndex. Rajpal leaves the practical boundary open: how complex must retrieval be to produce good results with the new offering?

Her team evaluates several distinct response failures: - Hallucinations. - Conflicting instructions. - Unnecessary verbosity: a simple question answered with an unwanted ten-point list. The team checks terseness internally, though Rajpal says it has no publicly available terse-response validator.

The interviewer recalls another failure from a closed-door session: a GPT asked to write a blog post instead promised to do it the next day. A conversationally plausible reply can still fail to perform the requested work.

Valid JSON and schema compliance are separate guarantees

Rajpal is enthusiastic about JSON generation. The ensuing discussion distinguishes two promises an application might rely on: - Syntactically valid JSON can be parsed as JSON. - Schema-compliant JSON also matches the structure requested by the application. The speakers interpret the announcement as guaranteeing the first, with the second still unguaranteed. This is their provisional assessment on the day: one had not tried the new function-calling release, and the other had not read the public documentation.

Reported JSON failures include unbalanced brackets, context-length limits, and quotation handling in very long strings. Earlier function-calling generations are also described as failing to guarantee schema compliance. A speaker speculates that the new guarantee uses constrained decoding, but the implementation is unconfirmed. They expect provider-controlled decoding capabilities to make more sense than improvised application workarounds and wonder whether other providers will adopt them.

Assistant specialization and guardrails as infrastructure

The GPT marketplace raises an unresolved product question: how specific should an assistant be? A generic sales assistant or SQL generator could compete with an assistant tailored to one industry and one stage of the sales process. Easy natural-language creation might also change work habits: when a recurring task becomes annoying, would people instinctively spend a few minutes building an assistant? These are questions about future adoption, not demonstrated productivity gains.

For the interviewer, natural-language creation feels almost like a new operating system, serving a no-code audience beyond their developer-focused work. The conversation then returns to what it takes to make these applications useful in production.

The guest discussing their guardrails talk argues that applications built on nondeterministic language models eventually need controls to deliver useful results. The disagreement concerns where guardrails belong in the stack. The speakers describe an OpenAI presentation as placing them in the initial user-experience layer; the guest sees them primarily as infrastructure.

The proposed process begins with a bare-bones application: 1. Identify the risks that matter for that application. 2. Verify whether those risks occur. 3. Quantify the observed problems. 4. Mitigate them. Guardrails follow the application’s actual risks and the evidence of their occurrence.

Open models need adaptation—and task-specific comparisons

The closing conversation turns to Nous Research, a community collecting datasets and fine-tuning open models. It is described as growing from Discord into a network of contributors. Its datasets draw on open and closed sources, with releases carrying different licenses. The discussion connects increased fine-tuning activity to commercially usable base models: Llama 2 allowed commercial use, while Mistral released its model under Apache 2 with a BitTorrent link.

Running a model locally still leaves adaptation work. Cost and exposure to provider changes are presented as reasons companies consider their own hardware. Adapting a base model to a company’s needs creates a role for specialist fine-tuning groups such as Nous Research and Alignment Labs.

Hermes is discussed in connection with an instruction dataset of roughly 900,000 instructions and a recent base-model switch from Llama to Mistral, reportedly for better performance. The speaker explicitly does not know the dataset’s provenance. Frequent releases create a separate selection problem: deciding which models deserve engineering attention when even early-month updates can feel obsolete by a monthly recap.

Parameter count is an incomplete proxy for capability. A speaker argues that smaller models trained longer can outperform larger ones, citing Hugging Face’s 7B Zephyr against Llama 13B. Both participants restrict that comparison to some tasks; no benchmark names, scores, or evaluation conditions accompany it. The exchange also questions whether evaluations represent useful work and whether models can be over-tuned to them.

The open-model community moves from Discord to the club

Discord, X/Twitter Spaces, and the weekly ThursdAI discussion are described as places where the fine-tuning community follows releases and exchanges knowledge. The closing party comparison gives that online community a physical setting:

- OpenAI’s official gathering is recalled as a formal art-museum event with live jazz and business networking. - Nous Research’s unofficial gathering takes place at a club on Folsom Street in San Francisco, beginning around the time the official party ends at 8 p.m.

One participant interprets the unofficial gathering as an opportunity to promote open AI while developers are already in town. The part closes with their impression of Twitter culture appearing in real life, with recognizable currents of techno-optimism and effective acceleration.