Orchestra AIBy Hyperdrift

Orchestra AI by Hyperdrift · Field notes

The AI-native
organisation.

See what happens when agents become part of the work. Accounts of the systems we built, the decisions we kept, and what your business could do with the same ideas.

11 articles · press / to search

  1. 02

    Priorities / Standup

    AI daily briefs: turn activity into useful priorities

    Standup reads public GitHub activity and returns a short, evidenced set of priorities. Its ordering rule shows what makes an AI brief useful enough to act on.

    Public project
    Read →
  2. 03

    AI engineering / Databases and agent state

    Lakebase vs MongoDB and Cosmos DB: which approach fits?

    Compare Lakebase’s Postgres approach with MongoDB and Cosmos DB document models: relationships, transactions, use cases and when Databricks integration matters.

    Illustrative decision guide
    Read →
  3. 04

    AI engineering / Streaming and event contracts

    LangChain vs Databricks AppKit for agent streaming

    LangChain supplies agent updates; Databricks AppKit adds an integrated app server and agent host. Compare streaming, SSE, approval and recovery responsibilities.

    Illustrative architecture guide
    Read →
  4. 05

    Conversation / Hyperdrift First Officer

    The dashboard that speaks first

    A chief of staff walks in and says: three things need you today. We built that for a one-founder fleet. You talk, it answers in under a second, an agent acts, and it reports back.

    Live, and open source
    Read →
  5. 06

    History and human capability / UI and accessibility

    Is UI holding us back?

    New interfaces can remove work or move it into checking and correction. A historical argument for judging the whole task.

    Historical synthesis
    Read →
  6. 07

    Accessibility today / UI and accessibility

    Web accessibility: can people finish the job?

    An accessible button is useful. An accessible way to finish is the point. What the current evidence tells us about agents and access.

    Research and proposed evaluation
    Read →
  7. 08

    WebMCP and shared state / UI and accessibility

    Stop making agents hunt for buttons

    WebMCP lets a page expose actions to a browser agent. Radar shows how that can keep the person and agent working in the same place.

    Radar implementation and draft specification
    Read →
  8. 09

    Traction / First Officer / UI and accessibility

    A spoken promise is not a completed action

    A Cargo recovery request becomes an action, a checked result and a spoken report. What this bounded demonstration can teach app designers.

    Recorded sandbox demonstration
    Read →
  9. 10

    Voice through MCP / UI and accessibility

    Say the job once. Keep control of the result.

    Dictating to an assistant can become a way to direct connected tools. Our proposed experiment starts with a scoped read and a draft.

    Proposed experiment
    Read →
  10. 11

    The future of UI / UI and accessibility

    Your work should survive a change of interface

    Speak, inspect, correct and continue. A future interface should preserve the task when the person changes how they interact.

    Design position and research agenda
    Read →

Where could this help you?

Bring one workflow, a question or a product you want to improve. We’ll work out a useful first step together.

Describe your workflow →