America.gov Put a Chatbot in Front of 29,000 Government Sites, OpenAI Gave Agents Their Own Computers, and a Claude Sign-In Outage Reminded Everyone About Dependencies

Three stories from the last few days look unrelated: a government portal, a developer conference and a service outage. Read together they describe the same engineering problem, which is that a chatbot's behavior, runtime and availability all depend on things you do not fully control. Here is what happened and what to take from it.

1. America.gov: A Chatbot as the Front Door, and a Policy That Moved in a Day

On September 29 the Trump administration launched America.gov, a portal that puts AI chatbots at its core as a single entry point to roughly 29,000 federal websites. Reporting says it is powered by Google's Gemini and xAI's Grok and was initially pitched at tasks such as job postings, passports, Medicare, veterans' benefits and campsite searches.

What drew attention was not the plumbing but the answers. Multiple outlets reported that the bot initially contradicted the president on topics such as the 2020 election and the January 6 attack, and that a day later it had stopped answering some political questions. We have not been able to read the full coverage, so treat the details as reported rather than confirmed, and note that the cause of the change has not been established in what we saw.

The engineering lesson holds either way. A chatbot's behavior is a deployed artifact that can change overnight, through a system prompt edit, a classifier threshold or a model swap, and users and journalists will notice. Teams shipping public-facing assistants should version prompts and policy configs, keep a fixed regression set of sensitive questions, and run it on every change so that a behavior shift is a decision someone made rather than a surprise.

2. DevDay: The Agent Gets a Computer

OpenAI held DevDay in San Francisco on September 29, and early coverage centers on always-on agents: assistants that keep working after you close the tab, using connected apps and a dedicated cloud computer, aimed first at higher-tier and business users. Pre-event reporting had pointed to this direction, and some roundups claim specific model names and prices that we could not corroborate, so we are leaving those out.

The shift matters for builders because a chat turn is request and response, while an always-on agent is a long-lived process. That changes what you must design: where state lives, how a run is paused or killed, what credentials it holds while nobody is watching, and how it reports back. Teams that already treat a chat as a stateless HTTP call will need a job model underneath, with explicit budgets, timeouts and an audit log of every action taken.

3. A Sign-In Outage Is Still an Outage

Anthropic reported elevated errors across claude.ai, the API and Claude Code starting at 14:21 UTC on September 29. According to the report we saw, a partial fix was followed by a second failure that blocked sign-ins, new chats, voice, purchases and file uploads until about 14:59 UTC. Third-party trackers describe a longer window, so duration is disputed.

Authentication failures are a useful reminder that "the model is up" is not the same as "my product works". If your assistant depends on one provider's login or API, an incident there is your incident. A thin fallback layer is cheap insurance:

async function chatWithFallback(providers: ChatProvider[], req: ChatRequest) {
  let lastError: unknown;
  for (const p of providers) {
    try {
      return await p.stream(req, { timeoutMs: 8000 });
    } catch (err) {
      lastError = err; // log provider + error class for the post-mortem
    }
  }
  throw lastError;
}

Test it by failing the primary on purpose. A fallback you have never exercised is a hope, not a plan. A useful visual for this section would be a timeline of the incident beside your own error-rate graph, showing how fast a fallback would have taken over.

Conclusion

Behavior drifts, agents outlive the request, and providers go down. The common thread is that the reliable parts of a chatbot are the ones you wrap in your own tests, budgets and fallbacks. Version the policy, bound the agent, and rehearse the outage.

— Maya