Building AGI in Real Time — Part 3 of 3: From Model Capability to Useful Agents

Safety must keep up with changing capabilities

When OpenAI first built GPT-3, the techniques one speaker expected would make later systems safe to deploy differed from those that ultimately worked. That mismatch opens Part 3 of the DevDay 2024 conversation: both the problems and the available remedies change as models become more capable.

The proposed response is iterative deployment: anticipate the next capabilities, make the resulting system safe to release, and learn from its use. Better reasoning is presented as expanding the tools available for alignment and safety across the system stack, while creating new challenges. The work proceeds on two horizons: - Prepare the next deployment: solve the problems that stand between a particular system and its release. This receives most of the effort. - Investigate continued capability growth: study distant, potentially catastrophic scenarios, where actionable responses are less clear and sometimes require backtracking.

Careful public release complements internal testing. Staff and hired red teams cannot anticipate everything outside users will try; deployment reveals useful applications as well as failures. The speakers expect external pressure testing to become especially important as agents act in the world over longer periods.

Agents need sustained action and sustained trust

o1 and its successors are presented as a foundation for agents: systems that reason about difficult problems, break them into simpler ones, and act on those subproblems through repeated interactions with environments or people. The envisioned advance is work equivalent to several days of effort by a highly capable human. A speaker predicts that agents will become a major development in 2025, while acknowledging that their societal effects will remain uncertain until people use them.

A speculative adoption scenario makes the expected shift concrete: an agent completes a month of human work in an hour, then the user wants ten agents running together, and eventually a thousand. These figures illustrate changing expectations, not demonstrated speed or concurrency. OpenAI expects its own applications to represent only a narrow share of what developers build on the platform.

For computer-controlling agents, reliability and trust may take longer than capability. A respondent judges the underlying capability to be getting close, while identifying safety, alignment, robustness, and reliability as the main hurdles to entrusting an agent with a computer.

Safety precautions also have costs: they can delay access to beneficial tools. A speaker says o1 could have shipped sooner without its safety and alignment work, but with problems they were unwilling to accept. They characterize those potential costs as manageable for o1 and possibly unacceptable for a hypothetical later model, referred to as “o3 or whatever” in this 2024 discussion.

For requested offensive content, the response broadly favors following the user’s wishes, with exceptions. The stated approach is to start conservatively, distinguish actual harms from theoretical ones, and relax restrictions over time. It allows for mistakes in both directions: excessive restriction and insufficient caution.

Build where the model almost works

The startup advice turns capability growth into a product-selection rule: target a use case that current models narrowly fail to handle. Early adopters may tolerate its limitations; a subsequent model improvement could make the experience compelling. Products designed only around capabilities that already work well may soon feel dated. Finding the right boundary, the speaker emphasizes, is difficult.

An impressive AI service still needs a viable business, a defensible strategy, and advantages that accumulate over time. Durability remains company-building work. The excitement around AI can make a technical demonstration feel like a complete business when it is only part of one.

Voice interaction introduces a different product boundary. One speaker recalls involuntarily using ordinary social courtesies with the first voice-mode beta and feeling that a person might be present, despite knowing it was AI. They reject deliberately manipulative personality tactics but identify a harder problem: natural interaction can itself trigger social responses. Making voice feel more human may create safety and alignment questions without an explicit attempt to manipulate users.

Ship new capabilities—and help users discover them

The immediate developer commitment is to add system prompts, structured outputs, and function calling to o1 by the end of 2024. Function calling gives a model access to external tools and information. The initial o1 release is framed as a tradeoff: learn from real usage sooner or wait for feature parity with other models.

A speaker uses a GPT-2-to-GPT-4 analogy to convey how early they consider o1’s development. They urge developers to plan for rapid gains in intelligence, predicting that the following year’s improvement will feel larger than the advance from GPT-4 Turbo to o1.

Asked about competing products, the speakers praise two distinct ways of organizing an experience: - NotebookLM’s podcast format: Google’s product receives praise for offering something new and for its podcast-style voices. One speaker recounts a suggested use: upload a LinkedIn profile as a PDF to generate two hosts discussing its owner’s accomplishments. - Projects as temporary workspaces: Anthropic’s Projects are described as something to establish for a purpose and later leave behind. The speaker contrasts that mental model with GPTs, described as reusable creations intended to persist.

Future capabilities do not excuse today’s bugs. A speaker reports that ChatGPT serves more than 200 million people weekly and argues that those users cannot be asked to tolerate unresolved problems for months while waiting for improvements. Discovery is another immediate problem: a newcomer can type a greeting, receive an offer of help, have no idea what to ask next, and leave without finding anything useful.

Onboarding must teach useful applications and keep teaching as models gain capabilities. The speakers describe OpenAI’s evolution from an entirely research-focused organization toward one that also fixes bugs and makes products usable. They continue to advocate incorporating frontier capabilities into developer APIs and first-party products even when those capabilities only partly work, expecting them to improve.

That philosophy also shapes the answer about specialized agent models. Agentic use is a priority, but the respondent does not commit to a separate model family. Their position is that stronger reasoning should underpin stronger agents, with tool use and function calling added to make those capabilities actionable.

Internal use reveals workflows worth building

OpenAI makes model checkpoints available to staff before training finishes, encouraging experimentation in development, research, and capability discovery. This internal use informs what to productize next. At the time of the discussion, a respondent says the company has no o1-based employees; deploying agents into internal systems is something it intends to try.

Existing uses include two bounded workflows: - Customer support: bots answer external questions and staff questions on Slack. A respondent roughly estimates that the support team is one-fifth the size it would otherwise need to be, without providing a staffing baseline or measurement method. - Security triage: models sift incoming information and highlight items for human review, extending coverage beyond what staff could manually inspect.

The engineering emphasis is performance of the end-to-end workflow. A respondent describes connecting models with different strengths so the overall process can work well despite mistakes by individual components. This is a design principle; no particular architecture or evaluation results accompany it.

Roadmap priorities and release restrictions shape access

Offline models are described as desirable but low priority because of limited resources and bandwidth, with no release expected in 2024.

For government adoption, the advice is to start learning with existing models rather than wait for artificial general intelligence (AGI). Agencies could automate repetitive workflows and accumulate experience as capabilities improve. The respondent cites partnerships involving Pennsylvania and USAID.

On open source, support in principle is separated from roadmap priority. A speaker says substantial efforts have repeatedly lost out to other work. The desired contribution would fill a meaningful gap: given what they describe as strong existing open models, especially for on-device use, a small benchmark improvement would not be enough.

Advanced Voice Mode’s singing restriction illustrates a different release constraint. The team wanted singing, but shipped before refining classifiers and filters to distinguish copyrighted music from permissible material. A respondent cites missing licenses and the consequences of mistakes, while naming Happy Birthday as something they wanted to allow. Developer and first-party products might have different restrictions, but developer access would not remove the company’s legal constraints.

Long context: practical capacity versus a lifetime of information

Asked how much information models will be able to take into account at once, and how that will balance against information retrieval, a respondent separates two ambitions: - Practical long context: roughly 10 million tokens, with enough speed and accuracy to make supplying large amounts of material useful. The forecast is months from the 2024 discussion. - Lifetime-scale context: roughly 10 trillion tokens, framed as enough to include every piece of information someone has encountered. The respondent expects effectively infinite context within a decade, while acknowledging that it requires research breakthroughs.

Both are forecasts, not demonstrated results. The respondent says long-context usage has been lower than expected without explaining why. The balance between larger context windows and retrieval remains unanswered.

An interface that already knows the task

The final audience question turns to interaction design. A respondent recounts using ChatGPT on a phone to translate English into Korean and Korean into English during a business conversation. They report completing the conversation, though the anecdote includes no independent assessment of translation quality.

The product opportunity is an interface with the user’s intent already established. A dedicated pocket translator could begin in translation mode, sparing users from configuring a general-purpose assistant. The respondent sees room for developers to create such specific experiences while OpenAI maintains a broad application that must keep up with changing model and agent capabilities.

The onstage discussion closes with a more speculative vision: an interface generated as a real-time video stream for each request. Users would speak or click within the stream while connected agents performed tasks. The speaker places this within a relatively small number of years, without a specific date or demonstration.

The coverage sign-off invites listeners to share feedback on the launches and guests through YouTube or Substack comments, with particular interest in personal experiences and demos built using that week’s releases.

Closing retrospective: working code is only part of software quality

After the sign-off, a retrospective discussion interprets the interviews as a move toward a developer platform surrounding the models: tools for fine-tuning, distillation for efficiency, evaluation, and real-time interaction. Its accounts of developer results are secondhand summaries of the interviews.

The retrospective connects function calling to external actions such as web searches and flight bookings, then argues that responsive voice assistants and real-time translation could help bring AI into mainstream use. These are potential applications; no latency measurements or translation-quality results accompany the argument.

One secondhand anecdote describes o1 turning an iPhone app idea into an architecture and connected components, with code that reportedly worked when placed into Xcode. The app’s complexity, iteration count, and testing scope are unspecified.

The consequential distinction is that working code is only one dimension of software quality. The retrospective argues that coding benchmarks do not fully capture what users and developers need: - Efficiency and maintainability: software must remain practical to run and change. - Integration: its components must work together. - Appearance and usability: a functioning React button is insufficient evidence of a good interface.

Another secondhand account describes a coding tool performing differently across JavaScript and C#, without identifying which performed better or supplying evaluation conditions. The retrospective treats this as an argument for diverse training data and adaptability, but the cause of the reported difference is not established.

The closing discussion returns to building applications just beyond current capabilities while retaining a defined customer, a real problem, and a business strategy. It leaves the tension between safety restrictions and beneficial access unresolved: making powerful capabilities broadly available still requires judgment about how to release them.