For the last several months, PeakOps has been a weekly brief and a daily attendance report.
That's what we told people. That's what our website said. That's what I demoed. "We send your operators a weekly intelligence brief every Monday morning. We send a daily attendance report at 7 AM. The brief synthesizes your POS data, time and attendance data, and review data into one narrative with dollar-valued recommendations."
And it worked. Operators loved it. Our pilot customers get the brief every Monday and act on it. Fouad at Bibos NY Pizza told us, "If it's in my face, I'll look at it. I'm not going to take 20 clicks to find that data."
So why change anything?
Because we were describing the product wrong. And the way you describe a product determines what it can become.
The Brief Was Always an Agent
Here's what the weekly intelligence brief actually does:
It runs autonomously on a schedule. It pulls data from multiple sources without being asked. It analyzes that data against historical baselines. It generates specific, prioritized recommendations with dollar amounts. It references what the operator did last time they saw a similar pattern. And it delivers its output without any human triggering it.
That's not a report. That's not a feature. That's an agent.
The daily attendance report does the same thing. It runs every morning at 7 AM. It pulls clock-in data from the operator's time and attendance system, compares it against scheduled shifts, identifies no-shows, late arrivals, missing clock-outs, and overtime. It flags when a pattern is recurring — same employee, same day of week, third time this quarter — and delivers the analysis before the operator has finished their coffee.
Also an agent.
We had agents. We were calling them features.
Why the Label Matters
You might think this is just semantics. Rename the brief, call it an "agent," ship the same product with trendier vocabulary. I thought that too, for about a week. Then I realized the label change unlocks three things that a "feature" framing never could.
First: agents multiply. Features don't.
When the weekly brief is a feature, operators ask "can you add a labor cost report?" and "can you add a review dashboard?" Each request is a feature request that requires engineering work, product decisions, and prioritization. The product grows linearly with our capacity to build things.
When the weekly brief is an agent, operators ask "can you watch my DoorDash rating at Toledo and alert me if it drops below 4.0?" That's not a feature request. That's a new agent — and the system can create it from a natural-language description without us writing a single line of code. The product grows with the operator's imagination, not our engineering bandwidth.
We launched with two system agents that ship out of the box. But the real product isn't the system agents — it's the one the operator builds themselves because their business has a specific problem none of ours anticipated.
Second: agents compound. Features reset.
A feature shows you data every time you open it. It doesn't remember what you did about the data last time. It doesn't track whether your decision worked. Next week, it shows you new data with no memory of what came before.
An agent remembers. Our Weekly Intelligence Brief agent doesn't just tell you that Sylvania is overstaffed on Tuesday lunch. It tells you that last time you saw this pattern, you added a prep cook instead of cutting shifts, and ticket times dropped 18%. It asks whether you want to try that again or try something different this time.
That's not a report with a good memory. That's institutional knowledge that normally lives in one person's head — and walks out the door when they leave. We call this the compounding intelligence loop, and it's the single most important thing in the product. Every decision the operator logs makes every agent smarter. After six months, the system doesn't just know your numbers. It knows your decisions.
Third: agents are a team. Features are a list.
This is the one I didn't expect to matter so much, but it changes how operators think about the product.
When I showed people a feature list — weekly brief, attendance report, labor analysis, review monitoring — they compared it to other feature lists. "Toast does some of that. My scheduling tool has attendance tracking. R365 has labor reports." Feature lists invite feature-by-feature comparison, and feature-by-feature comparison is a fight you lose against incumbents with ten years of development.
When I show people a team of named agents — the Weekly Intelligence Brief, the Daily Attendance Report, the Labor Cost Guardian, the Review Watchdog, the Sales Anomaly Detector — they don't compare features. They think about hiring. "I'm getting a team of analysts for $150 a location?" The conversation shifts from "what does it do" to "what do they do," and that shift changes everything about how the product is perceived.
The System Agents
Here's the team. The first two are live and running from day one. The rest are rolling out over the coming weeks.
Live now
The Weekly Intelligence Brief delivers a full cross-location analysis every Monday morning — synthesizing POS sales, time and attendance data, and guest reviews into a single narrative with dollar-valued recommendations. The Daily Attendance Report surfaces no-shows, late arrivals, missing clock-outs, overtime, and early departures every morning at 7 AM, flagging recurring patterns before they become turnover.
Rolling out
Revenue: The Flash Report gives an end-of-day sales snapshot. The Sales Anomaly Detector flags when any location deviates from its own baseline. The Menu Mix Monitor catches gradual channel and category shifts over 8+ week windows.
Cost: The Labor Cost Guardian watches labor as a percentage of revenue at every location and triggers when thresholds are breached. The Overtime Analyzer breaks overtime into three categories — backfill, extended shifts, and planned coverage — because most operators know their total OT number but not the composition.
Guests: The Review Watchdog monitors incoming reviews in real time across all platforms and triggers when sentiment clusters emerge. The Competitor Pulse tracks competitor review profiles near your locations and spots market-level shifts.
People: The New Hire Early Warning monitors employees in their first 60 days for signals that predict turnover — because catching a struggling hire at day 15 instead of losing them at day 45 saves $3,000 to $5,000.
These cover the four domains every restaurant operator cares about: revenue, cost, guests, and people. But they're the starting lineup, not the whole roster.
Custom Agents: Where This Gets Interesting
The piece I'm most excited about is custom agent creation. An operator can describe what they want in plain English and PeakOps creates an agent from the description.
"Alert me if any location's COGS exceeds 35% for two consecutive weeks"
becomes a COGS Threshold Monitor that checks weekly and sends an email with the specific location, trend, and recommendation.
"Watch Toledo's DoorDash rating and alert me if it drops below 4.0"
becomes a Toledo DoorDash Guard that checks daily and includes the specific reviews driving the change.
"When mid-shift revenue drops below $1,500 at Sylvania, draft a schedule adjustment"
becomes a Mid-Shift Optimizer that generates a schedule modification with estimated monthly savings.
No rules engine. No workflow builder. No configuration forms. The operator describes what they care about and the system handles the rest. And every custom agent feeds the same compounding loop — its recommendations get sharper as the operator logs decisions and the system measures outcomes.
An operator who starts with our system agents and ends up with 20 custom agents has built a deeply personalized intelligence layer that no competitor can replicate by copying features. That's a moat. Not a feature advantage — a moat.
What Actually Changed in the Product
Honestly? Less than you'd think. The brief still arrives Monday morning. The attendance report still runs at 7 AM. The data integrations are the same. The output quality is the same.
What changed is the architecture underneath and the surface on top.
Underneath: every piece of intelligence PeakOps delivers now runs through the same agent framework. Same trigger system, same scheduling, same output pipeline, same compounding loop. This means a custom agent created by an operator in plain English has the same capabilities as the system agents we built — it's not a second-class citizen.
On top: the product now presents itself as a team, not a tool. You don't open PeakOps to "check your dashboard." You open it to see what your agents found, what they recommend, and what happened since you last logged a decision. The nav has five destinations: Home, Agents, Performance, Actions, Locations. Performance is the scoreboard operators want, but the agents are the product. The dashboard is the verification layer. The agents do the thinking.
The Competitive Implication
This is the part I think about most.
The big restaurant tech companies — Toast, R365, MarketMan — are scrambling to add AI to their platforms. Intercom's CEO wrote a piece recently about how the only way traditional SaaS survives AI is through creative destruction: cannibalizing your own workflow tools to become an agent company. Intercom did it, going from near-zero growth to $400M ARR by killing $60M in existing revenue and redirecting 80% of R&D to their AI agent.
The incumbents in restaurant tech face exactly this problem. Their revenue depends on per-seat workflow tools — scheduling, inventory management, POS analytics. An AI agent that optimizes schedules automatically or surfaces the only three numbers that matter this week undermines the dashboards and reports those tools sell. Adding real AI intelligence risks competing with their own analytics upsell.
PeakOps has no legacy to destroy. We didn't pivot to agents from a dashboard company. We pivoted to agents from a brief company — and the brief was already an agent, we just didn't know it yet.
Our job now is to never accidentally become what the incumbents are trying to escape. No self-serve analytics. No drag-and-drop report builders. No feature-parity dashboards. If an operator needs a traditional dashboard, they already have one from Toast or R365. We're the intelligence layer on top — the team of agents that tells them what to do about the data those tools collect.
What's Next
We're onboarding operators now. The product is live, the first two agents are running, and real operators are getting real briefs with real recommendations every week. The remaining system agents are shipping over the coming weeks — each one built on the same framework, each one feeding the same compounding loop.
The next milestone is getting to the point where the compounding loop has enough history to produce measurably better recommendations over time. That's the promise — and we need 8 to 12 weeks of operator decisions logged before we can demonstrate it with data rather than narrative.
If you're running 5 to 50 restaurant locations and you're spending your Monday mornings pulling data from four different tools instead of making decisions, we should talk. The agents are ready to go to work.
This is Part 12 of The Pivot Chronicles, an ongoing series about building PeakOps. Previous parts cover predictive analytics, AI video analysis, engagement surveys, micro-checks, and the shift from daily digests to weekly briefs. This one is about the moment we realized the brief was never the product. The agents were. Start from Part 1.
Alistair Nicol is the founder of PeakOps. Reach him at alistair@getpeakops.com.