What’s New in Wire 4.x : Multi-Agent Development, dbt Charts, Agents Schema & More

We just released the 4.1.0 version of Wire, the plugin for Claude Code and Gemini CLI that brings our delivery blueprints, skills and best-practices to the AI-powered agentic coding tools provided by our partners at Anthropic and Google.

Our consulting team uses Wire to deliver client projects that build and upgrade your data platform, migrate your data warehouse and provide your AI agents with trusted numbers, evals and context layers.

And as with previous releases of the Wire Plugin, we also make it available as a public resource to our clients, individual developers and internal data teams to check-out and (non-competing) use, with full details including installation steps and worked examples available at docs.rittmananalytics.com.

What’s New in Wire 4.x

Wire 4.x introduces a large number of new user-facing and back-end features, including:

• Business rules discovery, an optional first step in several release types that records, per business domain, every competing definition of a metric together with the file it came from, what they disagree on, the decision and who approved it.
• dbt Charts, a dashboard layer written as YAML files that live in the dbt project next to the models and can be run locally, or uploaded and hosted in dbt Labs’s new dbt Charts managed service

• Agents Schema, dbt Labs’ new standard for putting the context an AI agent needs to query a warehouse inside that warehouse, in a schema named AGENTS
• Check-out the Release Notes in the Wire documentation for everything-else that’s new this latest release.

Release Director Model : A New Multi-Agent Architecture in Wire 4.x

The headline feature that underpins much of what’s new in Wire 4.x is a new multi-agent architecture that makes Wire both simpler to use and significantly more capable. We call this the Release Director Model.

In the previous releases of Wire, the way that users delivered, for example, a project that led with a dashboard mock which was then used as a basis for gathering detailed requirements and turning them into a full working Looker dashboard, was to use as series of Wire commands in Claude Code like this:

# Phase 1: Requirements (Day 1)
/wire:business-rules-generate <release-folder>
/wire:business-rules-validate <release-folder>
/wire:business-rules-review <release-folder>

/wire:requirements-generate <release-folder>
/wire:requirements-validate <release-folder>
/wire:requirements-review <release-folder>

# Phase 2: Interactive Dashboard Mocks (Day 1–2)
/wire:mockups-generate <release-folder> 
/wire:mockups-review <release-folder>

# Phase 3: Visualization Catalog (Day 2)
/wire:viz_catalog-generate <release-folder>

# Phase 4: Data Model (Day 2–3)
/wire:data_model-generate <release-folder>
/wire:data_model-validate <release-folder>
/wire:data_model-review <release-folder>

# Phase 5: Seed Data (Day 3)
/wire:seed_data-generate <release-folder>               
/wire:seed_data-validate <release-folder>
/wire:seed_data-review <release-folder>

# Phase 6: Development — seed-based (Days 3–5)
/wire:dbt-generate <release-folder>                     
/wire:dbt-validate <release-folder>
/wire:utils-run-dbt <release-folder>                    
/wire:dbt-review <release-folder>

Over time, though, we found that users preferred to tell Wire what they wanted in plain conversational language rather than memorise dozens of commands, options and modifiers across an ever-growing range of project types.

Around the same time, our agentic data migration work with Carwow’s data team pushed us in the same direction. Migrating their Snowflake data warehouse to Google BigQuery meant coordinating dozens of Claude agents working in parallel to translate dbt models and other components of the platform.

That led us to a new way of working with Wire. Instead of asking the user to choose and run individual commands, they worked through a single orchestration session in Claude Code. That session interpreted what the user wanted, broke the work into smaller tasks and delegated those tasks to specialist agents, which then ran the appropriate Wire commands on the user’s behalf.

This more hands-off and directional model of working with Wire was so successful and more easily adopted by users, that we’ve now made it the default for all types of work in this new 4.x release.

Multi-Agent Development in Wire, In-Practice

So what does this new, agentic way of working with Wire look like?

Let’s return to the same scenario: the user wants to start with a quick dashboard mock based on an initial set of client requirements, use that mock to refine and confirm those requirements, then progressively build it out into a working prototype that can ultimately be refactored into a production Looker dashboard.

 ▐▛███▛█   Claude Code v2.1.289
▝▜██████▀  Opus 5.5 (1M context) · Claude Team
 ▝▝   ▝▝   ~/github/wire-4-dashboard-first-demo

  Get to finished work sooner with Opus 5.5. Switch anytime with /model.

❯ i would like to create a looker and bigquery platform for core dynamics, but start by prototyping a       
  marketing analytics dashboard starting with a mock, develop that rapidly and then get onto a wider        
  program of work once that prototype (PoC) gets delivered and we win hearts-and-minds at the company. Can  
  you start this engagement with this dashboard first approach, focusing on marketing analytics and         
  whatever requirements you can find for this topic area in the SoW I've provided                           
  
...

⏺ The SoW is in the repo root. I'll start the engagement with the Wire new command, which sets up the
  engagement and the first release.

⏺ Skill(wire:new)
  ⎿  Successfully loaded skill · claude-fable-5

...

  Read 1 file (ctrl+o to expand)

⏺ I've read the SoW. Most settings come straight from it. Four choices are yours to make before I create
  anything.

Wire reads through the SoW (Statement of Work) and works-out what questions the user needs to answer before it can proceed further:

←  ☐ Build route  ☐ Tracker  ☐ Doc store  ☐ Client domain  ✔ Submit  →

How should the marketing PoC be built?

❯ 1. Seeded (Recommended)
     Build the mock, data model, Looker views and dashboards on generated sample data first. Repoint to real
     HubSpot, Salesforce and ad-platform data later. Fits a PoC: no wait for Fivetran or GCP access.
  2. Live data
     Skip sample data and build straight against real source tables. Only works if marketing data is already
     landing in BigQuery.
  3. Type something.
────────────────────────────────────────────────────────────────────────────────────────────────────────────
  4. Chat about this

Enter to select · Tab/Arrow keys to navigate · Esc to cancel

The user answers this and the other outstanding questions and tells Wire to go-ahead, and after a while Wire confirms that it has setup the scaffolding for this project release and confirms what it knows and what information is still outstanding from its review of the documentation so far.

⏺ I've set up the Core Dynamics engagement in Wire, with the marketing analytics proof of concept (PoC) as
  its first release. The release is "dashboard-first": mock the dashboards, agree them with marketing, build
  on sample data, then switch to real data. Nothing has been built yet; the next step is turning the SoW's
  marketing section into a requirements document.

⏺ There is no issue tracker, no document store and no automatic call-transcript sync, as you chose.

  Marketing requirements in the SoW (section 5.2)

  - Problem: about $2.1M a year in marketing spend, with only last-touch attribution in HubSpot. HubSpot and
    Salesforce are linked only by a weekly manual CSV export.
  - 3 dashboards:
    - MA-01 Demand Generation Performance (weekly)
    - MA-02 Multi-Touch Attribution (5 attribution models to choose from)
    - MA-03 Pipeline Contribution (monthly, for executives)
  - 6 business questions, covering:
    - lead-to-sales conversion by channel
    - customer acquisition cost (CAC) by channel
    - pipeline generated per dollar of spend
    - the full funnel by cohort
    - how long deals sit at each stage
    - which content appears in won deals
  - 6 warehouse tables: funnel events, campaign spend, attribution touches, revenue split across touches,
    campaign, and contact.
  - 7 data sources:
    - HubSpot
    - Salesforce
    - Google Ads, LinkedIn Ads and Meta Ads
    - Outreach.io
    - Clearbit

  Open items, recorded in the context file

  1. Transformation tool: the SoW names Dataform, but Wire's build step produces dbt. This needs a decision
     before the build starts.
  2. Timing: the SoW schedules marketing dashboards for weeks 15 to 16, after the data foundation is built.
     Bringing them forward should be agreed with Priya Nair and Rachel Summers, because payment milestone M4
     depends on them.
  3. Salesforce to HubSpot sync: SoW assumption 9 says attribution depends on this sync keeping contact IDs
     consistent. It has not been checked yet.

  Next step: run /wire:requirements-generate 01-marketing-analytics-poc. Once Rachel Summers approves the
  requirements, the dashboard mockups come next. Should I start the requirements now and commit the setup?

The user then checks what’s been produced, and then tells Wire to “drive for it” going forward, the cue to have the orchestration agent start using its fleet of specialist sub-agents to handle delivery for the user.

❯ yes please drive for me, go ahead  

⏺ Skill(wire:release-director)
  ⎿  Successfully loaded skill

⏺ Got it — I'll proceed with committing the setup and drafting the requirements, then pause for approval
  before moving further. Logging this plan and the release claim now.
  
⏺ Setup committed. Now drafting the requirements from the SoW's marketing section.

⏺ Skill(wire:requirements-generate)
  ⎿  Successfully loaded skill

⏺ I'll delegate the drafting to the discovery analyst agent, passing along your stated priorities (marketing
  first, then the wider programme) rather than asking again.

⏺ Dispatching the requirements lane now.

Then, going-forward, Wire’s orchestrating agent session will start handing-off tasks to specialised Wire agents working within their own lanes, each of them under the control of the sole orchestration agent. Those lane agents will then run the Wire commands that perform the steps in this release type, make use of Wire Skills and in some cases use tools exposed by the various MCP servers connected-into your Claude Code environment.

And, as you can see from the more detailed diagram below and in our documentation, components within each layer in the stack also write to logs, update status files and maintain state files so that the whole process is auditable and recoverable.

Going back to the terminal, Wire’s orchestration session starts by spawning a discovery-analyst agent to go-off and look further-into the requirements we’ve been given by the client.

⏺ wire:discovery-analyst:AGENT(Draft and validate marketing requirements)
  ⎿  Backgrounded agent (↓ to manage · ctrl+o to expand)
  
⏺ I've committed the setup and started the requirements draft. It is running in the background and has not
  finished yet.

  The draft works from the marketing section of the SoW. It uses the priorities you set:

  ┌───────────┬──────────────────────────────────────────────────────────────────────────────────────────┐
  │ Priority  │                                      What it covers                                      │
  ├───────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
  │ Primary   │ Marketing proof of concept: the 3 dashboards (MA-01 to MA-03), the 6 marketing questions │
  │           │  and the 6 marketing tables                                                              │
  ├───────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
  │ Secondary │ Only the platform and Looker pieces the proof of concept needs                           │
  ├───────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
  │ Future    │ Product, Customer, Operational and governance work, each listed as a later release       │
  └───────────┴──────────────────────────────────────────────────────────────────────────────────────────┘

  The draft will also list the 3 open items as questions for the client, plus any unclear SoW terms, such as
  how MQL and SQL are defined.

  When it finishes, I'll check the file and update the status record. I'll then bring you the summary for
  approval. You can approve it now, ask for changes, or hold it for Rachel Summers to sign off.

  Running: /wire:requirements-generate 01-marketing-analytics-poc, /wire:requirements-validate
  01-marketing-analytics-poc

New in Wire 4.1.0 : Wire Studio

Keeping-track of what’s Wire’s doing for you now the work is being handed-off to agents in their own session lanes, and so the 4.1.0 release introduces a new web-based viewer for what’s going on in your Wire session called Wire Studio. In the screenshot below we can see the the discovery agent running, gathering requirements that will once complete, be passed-back to the orchestration agent and made available for you to review in the project filesystem.

After a few minutes, the Wire’s orchestration session reports back on what’s been determined, what open questions remain and asks whether you’d like to park those for a moment and move on to the next two stages in release workflow.

⏺ Agent "Draft and validate marketing requirements" finished · 6m 48s

⏺ The work checks out — 19 functional requirements, 6 non-functional requirements, and 3 deliverables are on
  disk, with only 2 minor deviations noted. I'll update the record now.

⏺ The requirements draft is done and passes all 11 checks. It needs your approval before the dashboard
  mockups can start.

  What the draft contains
  (.wire/releases/01-marketing-analytics-poc/requirements/requirements_specification.md, committed)

  ┌──────────────────────────────────────────────────────────────────────────────┬───────┐
  │                                     Item                                     │ Count │
  ├──────────────────────────────────────────────────────────────────────────────┼───────┤
  │ Functional requirements: what the dashboards and metrics must do             │ 19    │
  ├──────────────────────────────────────────────────────────────────────────────┼───────┤
  │ Non-functional requirements: speed, access, refresh times, metric governance │ 6     │
  ├──────────────────────────────────────────────────────────────────────────────┼───────┤
  │ Deliverables in this release (dashboards MA-01, MA-02, MA-03)                │ 3     │
  ├──────────────────────────────────────────────────────────────────────────────┼───────┤
  │ Open questions for Core Dynamics                                             │ 12    │
  └──────────────────────────────────────────────────────────────────────────────┴───────┘

  Product, Customer and Operational analytics are listed as deferred, each with a suggested later release.

  Open questions that change the numbers. The ones marked † are needed before the mockups can show realistic
  figures:

  - † How Core Dynamics defines an MQL and an SQL (Rachel Summers, Niamh Collins)
  - † The rule for "marketing-sourced" versus "sales-sourced" pipeline (Rachel Summers, David Park)
  - Customer acquisition cost (CAC) is defined as sales plus marketing spend. Sales cost is not in any of
    the 7 marketing sources (Rachel Summers, James Petit).
  - What counts as a "new logo" for CAC, and whether CAC uses a trailing 90 days or quarters
  - How far back a touch counts towards attribution, and which content assets are tracked
  - The 3 items we already knew: Dataform or dbt, the timing change, and the Salesforce to HubSpot ID sync

  2 small problems I found while checking the lane's work

  - The document has 3 empty "reserved" sections (11 to 13), and the later sections are numbered 14 to 17
    instead of 11 to 13. This is a layout fault only. Fixing it means re-running the draft.
  - The lane added notes to decisions.md, which was outside the files it was allowed to write. The notes are
    accurate, and I've recorded the slip in the run log.

  My recommendation: approve it internally now. In a dashboard-first release, the mockup sessions with
  Rachel Summers are the natural place to settle the MQL, SQL and sourcing questions. Holding the draft for
  her formal sign-off first would delay the mock that is meant to win support. The questions stay listed as
  open either way.

  The choice is yours:

  1. Approve now. I record the approval under your name and start the mockups with you.
  2. Changes. Tell me what to change, for example the section numbering, and I'll re-run the draft.
  3. Hold for Rachel Summers to sign off. I record it as waiting on her, and nothing moves until she
     approves.

  Ran: /wire:requirements-generate 01-marketing-analytics-poc, /wire:requirements-validate
  01-marketing-analytics-poc
  Not run: /wire:mockups-generate 01-marketing-analytics-poc, gate: requirements review
  
  ❯ Approve now                                       

Once approval is given, you can see in Wire Studio where we are in the overall workflow

and the orchestration agent now creates two more agents, one to create the conceptual data model that such a dashboard would require, and another to design and build the actual dashboard mock.

Requirements approved and committed. The design phase is now open. Here is what can run next.

  Run plan: 01-marketing-analytics-poc, up to the mockup and conceptual model reviews

  #: 1
  Step: Build the dashboard mockups with you
  Type: command (foreground, interactive)
  Command: /wire:mockups-generate 01-marketing-analytics-poc
  Scope: design/mockups/
  Produces: Clickable Looker-style HTML mocks of MA-01, MA-02, MA-03, refined with you
  ────────────────────────────────────────
  #: 2
  Step: Draft the conceptual model (the business entities and how they relate: campaign, contact, touch,
  lead, opportunity, spend)
  Type: lane (data-designer)
  Command: /wire:conceptual_model-generate 01-marketing-analytics-poc
  Scope: design/conceptual_model* , lanes/conceptual_model.state.md
  Produces: Entity model and its check report
  ────────────────────────────────────────
  #: 3
  Step: Approve mockups and conceptual model
  Type: decision
  Command: director
  Scope: mockups review, conceptual_model review
  Produces: Your rulings; the run stops here

  Steps 1 and 2 run in parallel, because neither depends on the other.

  Not planned:

  - /wire:viz_catalog-generate 01-marketing-analytics-poc and /wire:data_model-generate
    01-marketing-analytics-poc. Both need the mockups approved first.
  - /wire:business-rules-generate 01-marketing-analytics-poc. This is optional (see the question below).

  One ruling is needed before step 2. The conceptual model has an advisory check: it expects agreed business
  rules first. Those rules would cover how MQL, SQL, marketing-sourced pipeline and CAC are defined, which
  is open questions C-3 to C-7. There are 2 options:

  - Skip for now (my recommendation). Draft the model with those definitions marked as placeholders, and
    settle them with Rachel Summers in the mockup sessions. I record the skip and the reason as ruling R-2.
  - Run business rules first. This adds /wire:business-rules-generate before step 2. It is the better route
    if you want the definitions agreed formally before any design. It needs time from Rachel Summers and
    Niamh Collins, which slows the proof of concept.

  go (with skip) / go (with business rules first) / adjust / cancel?

  Not run: /wire:mockups-generate 01-marketing-analytics-poc, /wire:conceptual_model-generate
  01-marketing-analytics-poc, gate: waiting for your go on the plan
  
⏺ wire:data-designer:AGENT(Draft and validate conceptual model)
  ⎿  Backgrounded agent (↓ to manage · ctrl+o to expand)

⏺ The conceptual model lane is running in the background. Starting the mockups with you now.

Going back to Wire Studio, you can see both of these agents, running in their own Claude Code lanes, running Wire commands and delivering the tasks for you.

After a while, the data-designer lane agent completes it’s work.

 ✻ Waiting for 2 background agents to finish

⏺ The conceptual model lane has finished. Checking its work before updating the record.

⏺ The conceptual model is done: 13 business entities and 18 links between them, passing all 12 checks. It is
  committed in design/conceptual_model.md. The mockup agent is still running.

  What the model covers

  - Channels, campaigns and daily spend.
  - Contacts, the companies they work for (with Clearbit firmographic data) and opportunities.
  - Every marketing touch: ads, forms, emails, page views, content and SDR outreach.
  - Funnel stage changes, and an attribution table that splits each opportunity's value across touches under
    all 5 models.
  - It covers all 6 marketing tables named in the SoW.

  Design choices the agent made:

  - A "lead" is a contact at an early funnel stage, not a separate entity.
  - Outreach.io SDR touches are folded into the single marketing touch record.

  The 9 definitions you chose to settle in the mockup sessions (ruling R-2) are marked as placeholders. The
  Salesforce to HubSpot contact link is flagged as the main risk.

  2 points to raise at review, not errors:

  - The text says SDR touches roll up into marketing touches, but the diagram does not draw that link.
  - No direct link between a contact and an opportunity. Attribution has to reach an opportunity through the
    company the contact works for, which is less precise than Salesforce contact roles. This is worth a
    decision before the data model.

  I'll hold this review until the mockups arrive, so you can review both together. The mockups may change
  the model.

  Ran: /wire:conceptual_model-generate 01-marketing-analytics-poc, /wire:conceptual_model-validate
  01-marketing-analytics-poc
  Running: /wire:mockups-generate 01-marketing-analytics-poc

Looking at the resulting conceptual model in Github, you can see how Wire has designed our conceptual model for us based on everything that’s been gathered, confirmed and recorded as required for the marketing analytics dashboards this release is designed to deliver.

A few minutes later, Wire’s orchestration session tells-us that the dashboard mocks we’re going to show to our stakeholder are now ready for viewing.

The three dashboard mockups are built and open in your browser. My checks found no problems, apart from minor dashes in some chart titles. They're committed to
  design/mockups/, together with a list of all 27 charts, tiles and tables and a dashboard spec.

  What each dashboard shows (sample data sized to Core Dynamics: about $175K a month of marketing spend)

  ┌────────────────────┬─────────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────────────┐
  │     Dashboard      │                       Headline tiles                        │                                Charts and tables                                 │
  ├────────────────────┼─────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────┤
  │ MA-01 Demand       │ Leads, MQLs, MQL to SQL rate, cost per MQL (about $392),    │ Funnel volume by week; conversion by stage; spend this month vs last; cost per   │
  │ Generation         │ pipeline generated                                          │ MQL and SQL by channel, with trend lines; top 10 campaigns                       │
  ├────────────────────┼─────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────┤
  │ MA-02 Attribution  │ Attributed revenue, active model, touches to close, days to │ Revenue by channel, which changes when you pick an attribution model (try the 5  │
  │                    │  close, content-influenced wins                             │ buttons); days per stage by channel; touches by segment; content in won deals    │
  ├────────────────────┼─────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────┤
  │ MA-03 Pipeline     │ Marketing-sourced pipeline, influenced revenue, CAC (about  │ Marketing-sourced vs sales-sourced by month; CAC by quarter against the 15%      │
  │ Contribution       │ $31K), return on spend (about 7.3 to 1), new logos          │ reduction target; return on spend by quarter                                     │
  └────────────────────┴─────────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────┘

  Each figure that depends on an unagreed definition has a small amber "Def to confirm" note. These cover MQL and SQL, the sourcing rule, CAC inputs and period, what counts
  as a new logo, the lookback window, and content assets.

  Things to know:

  - Your commit. At 17:40 you committed and pushed 2 of the mockups while the agent was still writing them. My later commits sit on top of yours, and I have not pushed them.
    Should I push?
  - Dashes. The mockups use dashes in some chart titles and campaign names, against the house style. I can have them removed in the next round.

  Next, the review. The mockups are the point of this release, so this is where we work through them together. For each dashboard you can:

  1. Approve as is. Once all 3 are approved, the chart list and data model can start.
  2. Tell me what to change. For example a tile, a chart type, a filter, or how the numbers look. I'll send the changes back to the mockup agent and reopen the updated
     files.
  3. Hold for Rachel Summers. I record the review as waiting on her sign-off.

  The conceptual model can wait until the mockups settle, since mockup changes may alter it.

  What would you like to change, if anything?

  Ran: /wire:mockups-generate 01-marketing-analytics-poc
  Not run: /wire:viz_catalog-generate 01-marketing-analytics-poc, gate: mockups review

Automatically-Generated Looker Dashboard Mocks

Google Chrome has automatically opened and is now showing, on three separate tabs, fully-clickable and realistic Looker dashboard mocks (with open items clearly labelled) ready for running past our Stakeholder, showing value in hours rather than the days or weeks this type of exercise would have taken in the past.

Interested? Find Out More

Rittman Analytics is a boutique data analytics consultancy that helps ambitious, digital-native businesses scale-up their approach to data, analytics and generative AI using Wire and our other AI technologies.

We’re authorised delivery partners for Google Cloud along with Oracle, Segment, Cube, Dagster, Preset, dbt Labs and Fivetran and are experts at helping you design an analytics solution that’s right for your organisation’s needs, use-cases and budget and working with you and your data team to successfully implement it.

If you’re looking for some help and assistance with your AI initiative or would just like to talk shop and share ideas and thoughts on what’s going on in your organisation and the wider data analytics world, contact us now to organise a 100%-free, no-obligation call. We’d love to hear from you!