AuRA

The Platform

The rebuilt AuRA, a plugin-based intelligence platform that runs YAML pipeline DAGs from dozens of data sources to briefs in many channels, with a visual pipeline editor.

Line drawing of a human brain made of fine white connections, with glowing blue nodes on lines radiating outward, on a dark background.

The rebuilt AuRA is built for analysts, researchers and organizations that need to stay on top of fast-moving information: surface what matters, vet it, and deliver it where it's needed. It keeps the ideas that worked in the original AuRA, back when it was called IntellectCascade (autonomous research, local models and produced media), and rebuilds everything around plugins.

Pipelines as graphs

A pipeline is a directed acyclic graph of stages. Each stage names a plugin and the stages it depends on, and the executor resolves the dependencies, runs independent branches in parallel and passes artifacts between them. Here is one of the example pipelines, in full:

financial_intelligence:
  description: "Monitor financial news → Research SEC filings → Analyze → Brief → Deliver"
  stages:
    - {name: ingest,           plugin_stage: datasource, plugin_name: financial_news}
    - {name: research_filings, plugin_stage: datasource, plugin_name: sec_edgar, depends_on: [ingest]}
    - {name: research_web,     plugin_stage: research,   plugin_name: google,    depends_on: [ingest]}
    - {name: analyze,          plugin_stage: llm,        plugin_name: local,     depends_on: [ingest, research_filings, research_web]}
    - {name: format_text,      plugin_stage: formatter,  plugin_name: written_brief, depends_on: [analyze]}
    - {name: format_audio,     plugin_stage: formatter,  plugin_name: audio_brief,   depends_on: [analyze]}
    - {name: synthesize,       plugin_stage: tts,        plugin_name: local,     depends_on: [format_audio]}
    - {name: deliver,          plugin_stage: delivery,   plugin_names: [filesystem, email, slack, rss_feed], depends_on: [format_text, synthesize]}

A financial news source watches for a breaking story. The same filings source that could monitor for new filings is used here in search mode, to find filings about the company in the story, while web search runs alongside it. Everything converges on the LLM, branches into a written brief and an audio brief, and fans out to four channels at once.

There's no auto-discovery. Plugins are declared in configuration, pipelines are declared in configuration, and every run can be traced back to a file someone can read. Configuration is layered, system defaults then per-user overrides then per-job overrides, so the system is multi-user from the ground up.

Everything is a plugin

Each stage has its own abstract interface, and every capability is an implementation of one:

  • Ingest: RSS and Atom, web pages, raw text, file upload, IMAP email, inbound webhooks, Kafka, directory watching, SharePoint and Confluence.
  • Data sources that both monitor and search: SEC EDGAR filings, financial news, market data, threat-intelligence feeds, CVE and NVD with known-exploited cross-referencing, OSINT, arXiv, PubMed, Semantic Scholar, X, Reddit, NewsAPI, SQL databases and any polled REST API.
  • Research: web search with deep page extraction.
  • LLM: in-process inference with llama.cpp on local models, with grammar-constrained structured output, or any chat-completions server.
  • Formatters: written, audio and video briefs.
  • Text-to-speech: Chatterbox locally, hosted voices, or Windows speech.
  • Media: audio processing, video compositing, image manipulation, and lip sync with MuseTalk 1.5 or LatentSync behind one interface.
  • Delivery: filesystem, YouTube, a podcast RSS feed, FTP and SFTP, Slack, email, Teams, SharePoint, outbound phone calls that play an audio brief, and a generic webhook with templated payloads that reaches anything else that accepts JSON.

Adding a capability means implementing a base class and declaring it. A corporate knowledge base, for example, becomes a data source by implementing two methods: one that yields new documents as they appear, and one that searches for documents about a topic. It is then usable in both the ingest and research stages of any pipeline.

Briefs, not content

The output concept changed from episodes to briefs. A written brief has an executive summary, key findings, analysis and recommendations. An audio brief is written for the ear, with an introduction, headlines, a deep dive and a closing. A video brief is a newscast with a lip-synced presenter, title cards and platform metadata. All three can come from the same analysis in one run, and each delivery plugin declares what kinds of artifact it accepts, so the pipeline routes the right files to the right channels without being told.

The operations center

The interface is a React operations center, designed dashboard-first: what AuRA is doing right now and what it produced recently.

  • Dashboard with active, completed and failed jobs, live progress bars and recent briefs marked by format.
  • Live job DAG. The pipeline's graph is drawn as nodes colored by stage type, and while a job runs each node changes state, pending, running, complete or failed, with animated edges showing data moving between stages. Updates stream from the server as events.
  • Pipeline editor. Drag plugins from a palette onto a canvas, draw connections to create dependencies, and configure each stage in a side panel. Validation blocks cycles and anything downstream of a delivery stage, and warns about softer problems, such as delivering raw ingested content with no analysis. It loads existing pipelines as templates, has undo and redo, and exports YAML.
  • Plugin browser grouped by stage, with each plugin's configuration schema, and data sources marked as monitor-and-search.
  • Brief viewer that renders written briefs and plays audio and video briefs inline.

The editor turns pipeline design from editing YAML into something an analyst or team lead can do, which was the point of the AuRA Chef idea from the previous generation.

Under the hood

The backend is Python with FastAPI and Pydantic, asynchronous throughout, with an on-disk artifact store organized by job and stage. Optional dependency groups mean an installation pulls in only what it uses: local LLM, local speech, Slack delivery, and so on. The rewrite shipped with a test suite of well over a hundred tests across the core executor, the base classes and representative plugins.