From Assistant Demos to Dependable Systems — DevDay, Part 3 of 4

A webcam request needs policy and personal context

An employee wants to expense a webcam above the company’s recommended budget. An assistant with the policy document can check the recommendation; an assistant with the employee’s spending data can also explain whether the purchase fits their remaining allowance. This is the opening example in Part 3 of the Latent Space DevDay recording: retrieved policy and personal context answer different questions.

A new message in a Slack budget-request channel triggers the assistant, which retrieves documents describing eligible expenses and spending rules. The speaker describes an internal implementation that also adds employee spending data to the message context. The resulting response can distinguish an item’s recommended budget from the employee’s remaining allowance, rather than treating them as the same limit.

Retrieval, data analysis, and code writing expand what these Zapier workflows—Zaps—can do. The speaker recommends three precautions before critical use: - Check accuracy: verify the information the workflow uses and produces. - Add human review: use approval steps while learning likely failures and operational constraints. - Limit the reach of free-form input: messages that trigger automation introduce prompt-injection risk. Start with internal workflows to learn those constraints.

The exchange ends with a lighter demonstration: alongside six advertised voices, the interviewer describes a prompt-induced pirate-speaking mode, informally presented as a secret seventh option.

MultiOn: browser actions beyond available APIs

Div Garg introduces MultiOn, an AI web agent for booking flights, ordering products, and buying dinner. He positions it as a way to act beyond available APIs, using existing logins or cookies to interact with a user’s personal accounts through the browser.

His proposed integration separates choosing from purchasing: ChatGPT helps select a burger, then MultiOn buys it. For flights, a ChatGPT request would launch a browser the user could watch while the agent completed the booking. Saved prompts would capture recurring workflows. Garg says MultiOn would handle payment, identity, and responsibility for risky actions; he interprets those risks as a reason for OpenAI to leave browser execution to third parties.

A planned MultiOn GPT would provide another entry point. Garg’s broader goal is to make the agent embeddable in existing applications through an API. With a ChatGPT plugin already in place, he expects to reuse that integration with little additional work.

GPT-4 Vision adds less when page parsing already works well. After more than a month of early Vision API access, Garg estimates that vision was particularly useful on roughly 5% of sites tried, mainly image-heavy ones. For roughly 95%, he considered optical character recognition—OCR—sufficient. These are informal estimates from an unspecified collection of websites.

The baseline matters: Garg says MultiOn’s parser compressed most websites to fewer than 3,000 tokens, making their textual representations manageable. The interviewer counters with a Discord screenshot demonstration whose OCR looked perfect to him. Garg agrees it is interesting, but regards vision as incremental for MultiOn’s system at that point. An image-oriented exception is memorable: he reports that a user had MultiOn swipe on Tinder and obtained a match.

Garg is more expansive about distribution. He speculates that a successful GPT marketplace could displace Apple’s App Store and imagines conversational systems taking over tasks performed on computers and phones within two years, while acknowledging uncertainty and the earlier plugin effort. Asked about research, he highlights Llama and Mistral; his suggestion that undisclosed factors contribute to Mistral’s performance remains speculation.

Bloop: context capacity is not context utilization

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 small models for natural-language code search; those models remained components of a larger pipeline. He also helped establish AI Tinkerer London as a startup-focused gathering in a technology community he saw as more weighted toward agencies and enterprises.

A larger context window—the amount of input a model can accept—does not establish how well it uses that input. Knight-Webb argues that standard evaluations inadequately measured this context utilization. Bloop tested Claude 2’s advertised 100,000-token window with a retrieval experiment: 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. Measure how many of the ten pieces the model retrieves.

He reports a steep accuracy decline between 1,000 and 10,000 tokens. Repeating the experiment with GPT-4 produced similar degradation: the 32K model retrieved only one of ten items in a longer-context test, compared with nine at 1,000 tokens. The exact longer prompt length, item placement, trial count, and scoring procedure are unspecified. The newly announced 128K window prompts a planned retest; no new result is reported.

Common output formats make model comparisons easier. Knight-Webb welcomes JSON as a way to reduce provider-specific output handling across commercial and open-source models. His concrete contrast is implementing function calling for one provider, then needing a different interpretation layer to try Anthropic.

Agent mechanics and product demand are separate questions

Asked why Bloop has not moved toward agents, Knight-Webb challenges the premise. Its pipeline already consists of GPT in a `while` loop with function calling, which he says clearly counted as an agent nine months earlier. What customers with large codebases had not supplied was a compelling reason to build an AutoGPT-style product.

The interviewer recalls OpenAI’s framing as custom knowledge, custom instructions, and actions. By that definition, Knight-Webb says Bloop had qualified since about February. In his account, users care about solving codebase problems more than the agent label. Bloop’s messaging had accordingly shifted from prominent model names toward the problems it solved.

That audience includes people who read more code than they write: - Designers can investigate the implications of a proposed interaction. - Product managers can examine the implementation behind a disputed development-time estimate.

The conversation briefly turns to fine-tuning and safety. Knight-Webb recounts a discussion with PhD students studying adversarial fine-tuning: allowing users to fine-tune a model may make preventing the removal of safety behavior very difficult, perhaps impossible. This is a secondhand research account without named models, attack methods, or measured results.

A Waymo ride puts reliability in context

The Bloop interview takes place inside a moving Waymo, both participants’ first ride in one. Its smooth progress invites comparison with Cruise. One speaker reports collision alerts on three of ten personal Cruise journeys, usually when a car ahead was trying to park. He suspects contact in one case and felt nothing in the other two; the alerts prompted an intercom check on passenger wellbeing. These were three alerts, with contact suspected in only one case.

Operating conditions limit the comparison. The interviewer suggests their current neighborhood may be easier to drive in. Louis says nighttime Cruise rides were fine, while a rush-hour ride took much longer because of its routing; traffic management is only his suspected explanation. When the interviewer describes self-driving as nearly solved, Louis points to London’s narrow roads, cyclists, and buses as reasons the experience may not transfer readily.

The interviewer finds a puzzling gap between the sophistication of the car carrying them and the comparatively primitive automation elsewhere in daily life. Louis raises another possibility: opacity may conceal failure modes. Hands-on GPT use exposes more people to model mistakes, while passengers know much less about the driving system. He acknowledges that he does not know how its pipelines are built.

Built-in retrieval leaves application questions open

Shreya Rajpal’s conversation begins with the AI Engineer Summit. She had worried that 18-minute talks would be too short, but ultimately found the format the right bite size; the interviewer says it was chosen for YouTube. Turning to DevDay, Rajpal singles out built-in retrieval and asks how much retrieval work application developers will still need to implement themselves.

In retrieval-augmented generation, retrieved material supplies information for an answer. Rajpal sees retrieval as the hard part: finding good material delivers much of the benefit, with generation adding comparatively little. The interviewer expects the API to cover basic patterns while advanced workflows still need tools such as LangChain and LlamaIndex. How much complexity good retrieval requires remains open.

Rajpal’s evaluation priorities include hallucinations, conflicting instructions, and terse responses—answering without defaulting to a verbose list. Her team checks terseness internally, though it has no public validator for it. The interviewer recalls a comic extreme from a closed-door demonstration: asked to write a blog post, a GPT replied that it would do so tomorrow.

JSON generation exposes two distinct failure modes: - Invalid syntax: output cannot be parsed. Examples include unbalanced brackets at context limits and quotation problems in long strings. - Schema mismatch: parsed output does not match the requested structure. Rajpal says earlier function-calling versions did not guarantee adherence.

Their provisional reading of the announcement is parseable JSON without a schema guarantee. The interviewer had not read the public documentation, and Rajpal had not tried that day’s function-calling release. She suspects generation is constrained to produce valid JSON, but this is an implementation hypothesis. She expects provider-controlled decoding to make more sense than application-level workarounds and wonders whether other providers will adopt it.

Easy assistant creation still needs guardrails

The GPT marketplace raises a question for Rajpal: how specialized must an assistant become to attract demand? A generic sales assistant or SQL generator could compete with assistants tailored to an industry and even a particular sales stage. Easier creation makes narrow specialization conceivable; which level succeeds remains unresolved.

The interviewer sees an emerging platform, almost an operating system, built around natural-language programming, and wonders how a developer-oriented practitioner fits into that no-code world. Rajpal imagines a possible new habit: encounter an annoying task, then spend five minutes making an assistant for it. This is a question about future behavior, not an observed productivity gain.

Her closing technical concern is dependable applications built on nondeterministic technology. She argues that a prototype only goes so far before guardrails—checks and mitigations for relevant risks—become necessary for users to obtain value. She sees OpenAI’s production presentation as validating that need, while differing in how she places guardrails in the application stack.

The distinction concerns their role: - User experience: the host describes OpenAI’s presentation as putting guardrails in the first layer, as part of the user experience. - Infrastructure: Rajpal primarily treats guardrails as a component of the application stack. She is still considering the UX framing.

Her Summit talk describes a procedure for adding guardrails once a bare-bones application exists: 1. Identify the risks that matter for the application. 2. Verify whether those failures occur. 3. Quantify failures when they occur. 4. Mitigate them.

Open models: local control and difficult comparisons

The final conversation turns to Alex Volkov and Nous Research, which he describes as a Discord community that grew into a network of contributors extending open models. Its work includes collecting datasets from open and more closed sources, releasing them under different licenses, and fine-tuning models such as Llama and Mistral.

Volkov connects the acceleration of community fine-tuning to Llama 2’s commercial-use license, contrasting that release with Mistral’s Apache 2 licensing and BitTorrent distribution. In his account, cost and exposure to provider changes push some companies toward running models on their own hardware. Local deployment creates demand for fine-tuning expertise to adapt those models to specific purposes.

He names Nous Research, Alignment Labs, and Skunk Works as emerging sources of that expertise. Some contributors, he says, had begun learning only six to eight months earlier and were already releasing leading models on the Hugging Face open-source leaderboard. No scores or evaluation conditions accompany that assessment.

The host brings up Hermes, reporting a recent move from a Llama base to Mistral because it apparently performed better. He describes Hermes as an instruction dataset containing 900,000 instructions, while acknowledging that he does not know its origin. The claimed improvement comes without precise model versions or benchmark results.

Release volume creates a selection problem. The host estimates that Nous releases roughly three models a week and asks which deserve attention. Volkov points to Thursday.ai’s weekly discussions, observing that rapid updates can make early-month developments feel outdated by the time a monthly recap appears.

Part 3 closes on the limits of model comparisons. Volkov argues that parameter count alone is an incomplete performance guide: longer training can help a smaller model outperform a larger one. His example is Hugging Face’s 7B Zephyr outperforming Llama 13B—qualified immediately by the host, and accepted by Volkov, as on some tasks. No tasks or scores are specified. Volkov’s final concern is that inadequate evaluation frameworks make these comparisons difficult to assess.