The 6 Ways to Use Claude as an Energy Manager (Most People Use One)

If you open Claude, type a technical question, read the answer, and close the tab, you are using one of six modes — and it is the least powerful one. The other five let Claude work directly on the data you already collect: interval meter exports, utility bills, point lists, M&V templates. For an energy manager the goal was never faster text. It is better decisions, made faster, on numbers you already have but rarely have time to interrogate. This is the ladder for getting there, rung by rung.

The framing borrows from AI educator Sabrina Ramonov, whose advice to “go deep on fewer tools” is exactly right for busy energy teams: pick one assistant and learn all of it, rather than dabbling across ten. What follows maps her six-feature progression onto the work an energy manager actually does — meter QA, monthly reporting, demand-spike investigations, and bill verification — and stays honest about where each rung helps and where it bites. The video below walks the same six steps; this is the field-guide version.

Step 1 — Chat: the one-sixth most people stop at

Chat is conversation. You type, Claude answers from what it knows, with no access to your files or systems. For an energy manager that is genuinely useful for surface-level work: interpreting a demand-charge clause in an Xcel or KPLC tariff schedule, decoding an ASHRAE term, explaining why coincident peak differs from facility peak, or tightening the language in a report.

Its limit is the whole point of this article: Chat does not know your building. It has never seen your meters, your baseline, or your bill. Ask it “is 587 kW high for my site?” and it can only reason in generalities. Treat it as a knowledgeable colleague you can phone but who has never visited the plant — and verify any number it volunteers, because it will sound just as confident when it is guessing.

Step 2 — Projects: stop re-explaining your facility

A Project is a reusable container that holds context — files and instructions — so every conversation inside it starts from what Claude already knows about you. Ramonov’s framing is that you stop starting from scratch.

For an energy manager this is where Chat stops being generic. Load the Project with your site list, the meter naming convention and point list, the tariff sheets, your reporting standard (ISO 50001 energy review structure, or the IPMVP option you use for M&V), and a one-page description of how each building runs. Now “why is plant load high today?” is answered against your facility’s vocabulary, not the internet’s.

A practical caution rooted in how the tool works: Claude’s working memory behaves like a whiteboard. Everything in the conversation lives on it until it fills, then older notes get summarized and detail is lost. A Project re-supplies the durable context each session so the important facts don’t fall off the board.

Step 3 — Cowork: hand it the actual files

Cowork — which Anthropic moved to general availability in April 2026 — is a desktop agent. With your permission it reads, edits, and creates files in folders you choose, and it hands back finished work rather than instructions. As Ramonov puts it, the difference between an assistant that describes a task and one that completes it is the whole game.

This is the rung where your raw signals enter. Drop a month of 15-minute interval CSVs, the utility bill PDFs, a few meter screenshots, and a reporting template into a folder, and ask for a reconciled monthly report. Cowork produces the formatted spreadsheet or memo — the bill reconciled against metered consumption, the variance called out, the M&V narrative drafted. The two-hour task of assembling a monthly pack becomes a review of a draft.

Keep the permission model tight here. Read-and-summarize is low risk; let it overwrite your source exports and you have lost your audit trail. Grant a working copy, not the original.

Step 4 — Claude Code: switch from prompts to goals

Claude Code is the most autonomous mode — it pursues a goal across many steps and tools instead of answering one prompt. Ramonov calls it “the closest thing to an AI employee,” and the shift in how you talk to it is real: you stop writing prompts and start setting objectives.

For meter work the objective looks like: “Review last month’s 15-minute interval data across all twelve meters. Flag every interval where demand exceeds 1.4× the trailing four-week median for the same hour and weekday. Cross-check my demand-charge calculation against the metered peak and the tariff schedule, and list the discrepancies.” Claude plans the steps, runs them, and reports back with the anomalies and the arithmetic checked.

Her single most useful tip transfers directly: plan first. “Ninety percent planning, ten percent building.” Have it lay out the approach and the assumptions before it touches the numbers, and review that plan — it is far cheaper to correct a method than to unwind a wrong conclusion. The same applies to model choice: a heavier model for genuinely hard analysis, a lighter one for quick lookups. Same task, different brain, different cost.

Step 5 — Skills: turn a good session into a repeatable procedure

A Skill is a procedure saved as a file — you teach Claude how to do something once, name it, and reuse it forever. Ramonov’s rule is “build once, reuse forever, improve over time,” and energy management is almost entirely recurring work, which makes it ideal ground.

The first three Skills most teams should build:

• Meter QA — the gap, spike, flatline, and unit-sanity checks you run on every new data pull, in one command.
• Monthly report — the full reconciliation-to-narrative pipeline from Step 3, codified so it runs identically every month.
• Demand-spike investigation — pull the interval around the peak, correlate with weather and runtime, and produce the candidate causes.

The discipline that makes Skills pay off is the same that makes a good SOP pay off: write down the steps you already trust, then let the machine run them consistently. A Skill is your meter-QA checklist that executes itself.

Step 6 — Connectors: close the loop to your meters

Connectors are the top rung. Built on the Model Context Protocol (MCP), they let Claude call your tools and data directly rather than waiting for you to export and upload. Ramonov’s line is the clearest test of why they matter: without a connector, Claude gives you instructions; with it, Claude does the work.

This is where the manual export step disappears. In our own stack we expose meter and portal data to Claude through MCP connectors — Claude can pull interval history straight from an eGauge device, or query the Eagles Portal for a facility’s consumption, bills, and alerts, then run Steps 4 and 5 on live data. The loop closes: meters feed the portal, the portal organizes the data, and Claude layers the analysis on top without anyone downloading a CSV.

A connector is also where authority concentrates, so it is where governance matters most. Scope each connection to the minimum it needs, keep read and write separate, and log what the model touches. A connected agent that can both read your meters and act on conclusions is powerful precisely because it removed the human checkpoint — put the checkpoint back deliberately, where it counts.

How to climb without falling off

The rungs are ordered for a reason; skipping is how this goes wrong.

1. Fix the data layer first. Meter coverage, naming, and units before anything else. The failure mode that has bitten hardest in real LLM-for-buildings deployments is not the model doing something dumb — it is the model confidently summarizing a meter tag that was quietly repurposed, or reporting a flow in GPM that was logged in L/min. A confident wrong answer is worse than no answer. (more on that here)
2. Live on Steps 1–2 for a few weeks. A well-loaded Project that answers real questions builds the credibility the rest of the program needs.
3. Add Cowork, then Skills. Automate one monthly report end-to-end. Show the team it saves their afternoon, not their job.
4. Approach Connectors with discipline. Read-only first, scoped tightly, logged. Earn write access; don’t grant it on day one.

Resist what Ramonov calls the shiny-object trap. The energy managers who get real leverage out of Claude are not the ones running every feature — they are the ones who climbed two or three rungs properly and trust what comes back. The model is the analyst’s hands. The engineer is still the one who signs the report.

Sources

• Anthropic — Claude Cowork product overview (claude.com/product/cowork) and Cowork general-availability announcement, April 2026
• Anthropic — Use Skills in Claude (support.claude.com/en/articles/12512180-use-skills-in-claude)
• Anthropic — Claude Code documentation (docs.claude.com/en/docs/claude-code)
• Model Context Protocol specification (modelcontextprotocol.io)
• Sabrina Ramonov — Claude framework and Cowork course (sabrina.dev), the six-feature progression this guide adapts for energy work
• IPMVP — International Performance Measurement and Verification Protocol; ISO 50001 energy review structure
• Eenovators Eagles Portal and eGauge MCP connector deployment notes (2026)

About the author

Chris Mbori

Founder of Eenovators Limited (East African ESCO), partnering with AIM Dynamics. Built Eagles and the ADM portal. AEE Energy Manager of the Year (Sub-Saharan Africa). 10 AEE certifications. Licensed Engineer. Field journal — hype-skeptical, field-tested.

More posts LinkedIn X Subscribe