Lab 1: Agentic Analysis

Track 2: Agentic Analytics · Day 2 breakout lab

In this lab you'll use Otto to build a comprehensive analysis from raw data sources. The business case: GreenTech Manufacturing is looking to tackle a critical sustainability challenge facing their five UK production facilities. The company consumes over 42 million kWh annually running energy-intensive operations, and with UK carbon offset costs at £85/ton CO2, their environmental impact is becoming a significant financial burden.

The key insight: the UK's electricity grid carbon intensity swings dramatically throughout the day. Your mission is to build an intelligent forecasting system that learns from 30 days of historical weather and carbon data to predict these low-carbon windows up to 7 days in advance, then identifies which flexible operations can be strategically shifted from high-carbon hours to clean-energy windows.

How this works

You're not writing code — Otto generates it for you. Your job is to ask good questions, inspect what Otto produces, and redirect when it's not quite right. Think of Otto as an analyst who works at the speed of thought — your job is to direct the work, not execute it.

Before you start

• Complete Hands-On Lab: Getting Agentic on Day 1
• You should have an Ascend account and an existing Project
• No SQL experience required — though it helps if you want to go deeper

The plan

1. Build the full carbon + operations optimization pipeline with a single prompt
2. Verify the pipeline runs successfully end-to-end

The dataset

You're working with five data sources that together tell the story of your manufacturing energy footprint:

Source	What it provides
UK Carbon Intensity API	Real-time and historical carbon intensity of the UK electricity grid
Open-Meteo Weather API	Historical and forecast weather data for predictive modeling
Facilities (CSV)	5 UK manufacturing sites with annual energy consumption and location
Machines (CSV)	125 machines with energy draw, type, and whether they're can be scheduled
Production Schedule (CSV)	Weekly shift patterns showing when each machine runs

Step 1: Build the data pipeline

Key concepts

A few terms you'll see in this lab:

• Flow — a data pipeline in Ascend. It's a connected set of steps that read, transform, and output data.
• Component — a single step in a flow. Components can be Python scripts that pull data from APIs, SQL queries that transform data, or file readers that load CSVs.
• Read component — a component that brings data into the flow from an external source (an API, a file, a database).
• Transform — a component that takes data from upstream components and reshapes or combines it, usually with SQL.
• SQL — structured query language, the standard way to query and transform tabular data. Otto writes SQL for you.

You're going to give Otto a single prompt, and it will build the entire optimization pipeline — combining our operations data with live weather and carbon intensity data to find the scheduling windows that save the most.

Important: Enable these settings first

Make sure these settings are configured at the bottom of the Otto panel before sending your prompt:

1. Attach a runtime — click + Runtime and select your Workspace. You should see your Workspace name appear once it's selected, indicating where Otto is working. This will also start your Workspace if it's been snoozing.
2. Web browsing — click the globe icon so it's highlighted (blue). This lets Otto fetch live data from APIs.
3. Auto-run queries — click the play icon (▶▶) so it's highlighted. This lets Otto run queries and flow runs without waiting for your manual approval each time.

Open Otto with Ctrl + I (or Cmd + I on Mac), start a new thread, and paste the following prompt:

We want to create a brand new flow. Before you build anything, I want 
you to create a plan in a markdown file and put it in a plan folder 
first that I will approve. In this flow we want to:

1. Use custom Python read components to ingest hourly weather data (from 
the OpenMeteo API - https://open-meteo.ascend.dev/) and carbon data 
(UK Carbon Intensity API - https://uk-carbon-intensity.ascend.dev/intensity) 
for the past 30 days. I only need the following latitude, longitude: 
(53.4808,-2.2426), (52.4862, -1.8904), (53.8008, -1.5491), 
(51.4545, -2.5879), (51.5074, -0.1278), make sure to hard code this 
in the OpenMeteo API read component. These ingestion components should 
gracefully handle schema changes, rate limits, and retries with 
exponential backoff. Use the live APIs only (never mock or fabricate 
data). Inspect a real sample response from each endpoint directly from 
the endpoint URL using HTTP before implementing parsing logic. You must 
inspect live API responses from the exact endpoint URLs you will 
implement against before writing any parser code, and you must use 
those observed payloads—not documentation summaries—as the source of 
truth for response structure.

2. Create a model to help us understand the impact of weather & time of 
day on carbon prices and impact. Use a carbon price assumption of 
£85/ton CO2 and use fixed tariff values of £0.135/kWh off-peak, 
£0.145/kWh mid-peak, and £0.155/kWh on-peak, with the model 
determining the hourly bucket assignment.

3. Ingest forecast data from the OpenMeteo API and create an hourly 
predictive model for carbon impact based on the weather forecast and 
time of day for the next 7 days, use the model that was built in 
step 2.

4. Layer in our own operations data to determine optimal operations 
windows and cost savings (both in carbon offsets and energy cost 
savings) based on rescheduling. The relevant data is in the data 
folder (read_facilities, read_machines, read_production_schedule). 
Build the carbon optimization model to maximize combined weekly 
financial savings (total_savings_gbp = energy_cost_savings_gbp + 
carbon_cost_savings_gbp)
Only recommend a reschedule when total_savings_gbp > 0 and 
carbon_savings_kg > 0. And only evaluate machines where 
schedulable = true

5. Produce a final interactive dashboard artifact for operations leaders 
showing: total combined savings, facility-level summary savings, 
machine-level recommended windows, energy cost savings, carbon 
savings in kg, carbon cost savings

IMPORTANT NOTES: Please make sure to build iteratively, running and 
testing components to validate that the output makes sense and 
understand the schema before building downstream components. Each time 
you make changes to correct an error, only run the component that you 
are fixing, you do not need to run the full flow. Once the whole 
pipeline is complete, then run it end to end.

Review the plan

Why plan first?

Asking an agent to plan before building is one of the most effective patterns in agentic work. A plan forces the agent to reason through the full problem — data sources, dependencies, edge cases — before writing any code. It gives you a checkpoint to catch misunderstandings early (wrong API, missing constraint, bad assumption) when they're cheap to fix, instead of after 15 minutes of building the wrong thing. It also gives the agent a reference document it can check back against as it builds, reducing drift and hallucination on long-running tasks.

Otto will create a markdown plan file outlining the components it intends to build, the data sources, the modeling approach, and the pipeline architecture. Before Otto starts building, review the plan and look for:

• Does it reference the correct API endpoints and coordinates?
• Does it include the carbon price (£85/ton) and tariff values you specified?
• Does it plan to use the schedulable column to filter machines?
• Does it include the iterative build-and-test approach?

Once you're satisfied, tell Otto to go ahead and build it.

Short on time? Skip the planning step

If you'd rather skip the planning step, you can give Otto a pre-built plan directly. Copy the plan below into a file at plan/plan.md in your project's Files panel, then tell Otto: "Use the plan in plan/plan.md to build the flow. Build iteratively — test each component before moving to the next."

Click to expand the pre-built plan

# Weather and Carbon Optimization Flow Plan

## Goal

Build a new flow that combines live hourly weather data, live UK carbon intensity data, forecasted weather, and internal operations schedules to identify machine rescheduling windows that improve both carbon impact and operating cost.

## Scope Requested

1. Ingest historical hourly weather data for the past 30 days from Open-Meteo for these hard-coded coordinates:
   - Manchester (53.4808, -2.2426)
   - Birmingham (52.4862, -1.8904)
   - Leeds (53.8008, -1.5491)
   - Bristol (51.4545, -2.5879)
   - London (51.5074, -0.1278)
2. Ingest historical carbon intensity data for the past 30 days from the UK Carbon Intensity API.
3. Build a model to understand the impact of weather and time of day on carbon cost / impact.
4. Ingest Open-Meteo forecast data and generate next-7-day hourly carbon impact predictions using the trained model.
5. Blend in operations data from read_facilities, read_machines, and read_production_schedule to recommend better operating windows.
6. Produce an interactive dashboard artifact for operations leaders.

## Non-Negotiable Implementation Constraints

- Use live APIs only. No mocks, placeholders, or fabricated records.
- Inspect real sample responses directly from the exact endpoint URLs before implementing parser logic.
- Use those observed payloads as the source of truth for parsing.
- Implement iteratively and validate outputs before building downstream components.
- When fixing an error, run only the component being fixed.
- Run the entire flow only after all components are complete and individually validated.

## Proposed New Assets

### New flow

- flows/weather_carbon_optimization/weather_carbon_optimization.yaml

### Planned components

#### Live ingestion

- read_weather_history.py — custom Python read for hourly historical weather
- read_carbon_history.py — custom Python read for historical carbon intensity
- read_weather_forecast.py — custom Python read for next-7-day hourly forecast

#### Modeling / preparation

- weather_carbon_training_dataset.py or .sql — align weather and carbon history hourly
- weather_carbon_model_features.py — derive hour-of-day / tariff / weather features
- weather_carbon_model.py — fit predictive model and output coefficients / scored history
- weather_carbon_forecast_scored.py — apply trained model to forecast horizon

#### Operations optimization

- read_facilities.yaml
- read_machines.yaml
- read_production_schedule.yaml
- operations_schedule_enriched.py or .sql
- operations_reschedule_candidates.py or .sql
- operations_optimization_recommendations.py or .sql

### Planned artifact

- Interactive dashboard application in applications/

## Design Decisions

### Tariff logic

Hard-code tariff values:
- off-peak: £0.135/kWh
- mid-peak: £0.145/kWh
- on-peak: £0.155/kWh

The model will derive an hourly bucket assignment from time of day.

### Carbon cost conversion

Hard-code carbon price assumption: £85 / ton CO2

### Operations optimization logic

Recommendations will only be produced when all are true:
- schedulable = true
- total_savings_gbp > 0
- carbon_savings_kg > 0

Optimization target: total_savings_gbp = energy_cost_savings_gbp + carbon_cost_savings_gbp

## Iterative Build Plan

### Phase 0 — Discovery before coding parsers
1. Inspect live Open-Meteo endpoint response from the exact historical URL pattern.
2. Inspect live Open-Meteo forecast endpoint response from the exact forecast URL pattern.
3. Inspect live UK Carbon Intensity endpoint response from the exact URL pattern.
4. Confirm response fields, timestamp format, units, nullability, and paging/range behavior.

### Phase 1 — Stand up the flow skeleton
1. Create the new flow directory and flow YAML.

### Phase 2 — Build and validate live ingestion components
1. Implement read_weather_history.py — run and inspect output.
2. Implement read_carbon_history.py — run and inspect output.
3. Implement read_weather_forecast.py — run and inspect output.

### Phase 3 — Build the historical modeling dataset
1. Align weather and carbon data by hour and geography.
2. Add tariff bucket and carbon-price-derived cost fields.
3. Validate row counts, null patterns, and key joins.

### Phase 4 — Build predictive model outputs
1. Implement training/model transform — validate predictions are sensible.
2. Score the 7-day forecast horizon — inspect predicted ranges.

### Phase 5 — Build optimization logic
1. Ingest facilities, machines, and production schedule.
2. Filter to schedulable = true machines only.
3. Evaluate candidate hourly windows and calculate savings.
4. Filter to positive-value recommendations only.

### Phase 6 — Build dashboard artifact
Dashboard should show: total combined savings, facility-level summary, machine-level recommended windows, energy cost savings, carbon savings in kg, carbon cost savings.

### Phase 7 — Final validation
1. Run the full flow end to end.
2. Validate dashboard against final recommendation outputs.

Watch Otto work

Sit back and watch. Otto will:

1. Create Python Read Components for weather and carbon intensity APIs
2. Build a weather forecast component for the next 7 days
3. Write SQL transforms to join all five data sources
4. Build a predictive model for carbon intensity
5. Calculate optimal scheduling windows for every machine
6. Test each component individually, then run the full flow end to end

Otto isn't generating code in isolation — it's looking at the actual data coming back from the APIs and cross-referencing it with your operations data. If something fails, Otto reads the actual error message and fixes the issue based on what it observed.

Otto will check in with you

This is a big project — Otto may take 50+ actions to build and debug the full pipeline. As a guardrail, Otto pauses after every 50 actions to ask for your approval before continuing. This prevents agents from running in continuous loops without supervision and spending unnecessary tokens. When you see the approval prompt, just confirm to let Otto keep going.

This takes 10–15 minutes

This is a complex pipeline with five data sources and a predictive model. Otto will likely hit errors and fix them over 5+ iterations. Each round, Otto reads the actual error logs and adjusts its approach. If Otto is still stuck after 15 minutes, try giving it a specific hint about the error you see in the flow run logs.

Your completed flow graph will look something like this — though your exact components and naming may differ depending on the approach Otto took:

Step 2: Verify the pipeline

Once the flow runs successfully, take a minute to spot-check the results before moving on to Lab 2. Your pipeline and results may be different from the other students in the bootcamp. This is to be expected. Otto will use the data in your project to build the pipeline and results, but has made some assumptions based on the data in your project that may lead to different outputs. To get an initial understanding of the results, you can ask Otto to give you a summary of the optimization results. The next lab will cover deeper insights into verifying agentic outputs.

Give me a quick summary of the optimization results. How many machines 
can we reschedule? What are the projected savings?

What just happened?

You just did in 20 minutes what would typically take days — connecting to two live APIs, ingesting 30 days of historical data, building a predictive model, cross-referencing with your operations data, and producing scheduling recommendations with cost savings. Otto handled the Python, SQL, and API calls. You directed the analysis. That's the division of labor that scales.

You've completed Lab 1!

By the end of this lab, you should have:

• Built the carbon + operations optimization pipeline from a single prompt
• Verified the pipeline runs end-to-end
• Spot-checked the optimization results

Need help? Ask a bootcamp instructor or reach out in the Ascend Community Slack.

Next steps

Continue to Lab 2: Verifying Agent Output to explore the data, verify the optimization logic, and build visualizations you'd be confident presenting to an operations VP.

Questions?

Reach out to your bootcamp instructors or support@ascend.io.