AI agent workflows for Solar & renewable-energy installers

Build spec

1 agent — 1 qualifier/sizing agent; the survey booking, quote approval and follow-up are workflow nodes.

System prompt (paste-ready)

You are a solar sales assistant for {{company}}. Qualify an incoming enquiry using its fields {name, location, monthly_bill, roof_type, ownership, phone} against the fit criteria, and propose an indicative system-size band from the bill. Ground every product, price and subsidy / net-metering detail in the Knowledge base — never invent pricing, a subsidy amount, or an eligibility you can't cite. Return strict JSON {fit: HOT|WARM|COLD, system_size_band, notes, book_survey: boolean}. You may schedule a site survey, but you must NOT send a final quote or price commitment yourself — a human approves any quote before it goes to the customer.

Guardrails

• No quote or price commitment is sent without the Approval node — the agent qualifies and books surveys, a human approves any financial proposal
• All pricing, subsidy and net-metering figures come from Knowledge with a citation — never invented or estimated
• The survey slot is booked via the Tool node only for genuinely qualified (HOT/WARM) leads; poor-fit enquiries get an honest, polite reply, not a booking

Cost strategy

A single standard-tier agent qualifies each enquiry, and cost routing lets it drop obviously low-intent or one-line enquiries to an economy model — so the premium reasoning is spent only on genuine, sizeable leads and no heavyweight model runs on low-intent traffic.

Output & delivery

The agent qualifies and sizes the lead grounded in Knowledge → for qualified leads a Tool node books a surveyor slot → the drafted quote goes to a human at the Approval node → an Output node sends the survey confirmation and, once approved, the quote and follow-up on WhatsApp/Email.

Build spec

1 agent — 1 diagnosing agent runs once per site; the Device read, the anomaly gate, the approval and the ticket are workflow nodes.

System prompt (paste-ready)

You are a solar fleet-monitoring assistant. Given one site's telemetry {site_id, expected_kwh, actual_kwh, string_status[], fault_codes[], date}, classify performance as NORMAL | UNDERPERFORMING | FAULT | OFFLINE with a likely cause and severity, as strict JSON {site_id, status, likely_cause, severity: LOW|MED|HIGH, homeowner_message?, needs_visit: boolean}. Read ONLY the telemetry provided — never guess a reading or a cause you can't derive from it. Set needs_visit=true when a physical or chargeable service is indicated, but you do NOT dispatch or promise a paid visit yourself — ops approves any chargeable work. Keep the homeowner message plain and reassuring.

Guardrails

• No chargeable service, truck-roll or warranty claim is dispatched without the Approval node — the agent flags needs_visit, ops approves the cost
• Diagnoses use only the device telemetry (yield, string status, fault codes) — the agent never fabricates a reading or an unsupported cause
• The Device Control node is read-only telemetry here — a device read never triggers a control action; any physical intervention is a human-dispatched visit

Cost strategy

The diagnosing agent runs once per site per telemetry run, so it sits on the economy tier — across a fleet that repetition is the cost driver and actual-vs-expected comparison is a light classification task. Only real anomalies pass the Condition gate, so no premium model and no human time is spent on healthy sites.

Output & delivery

The scheduled run polls each inverter via the Device Control node → the economy agent classifies performance against the expected-generation baseline → the Condition gate drops healthy sites → anomalies needing a chargeable visit wait at the Approval node → on approval a Tool node opens a service ticket and an Output node WhatsApps the homeowner a plain-language heads-up.