It isn’t true. Or it’s true only if you assume “AI” means the realtime, instant-answer chat you get from the paid services. Drop that constraint and free models become useful. One booked a real meeting on my calendar this morning.

The shape of a $0 personal assistant

I wanted something small and unsexy. An assistant that can look at my Google Calendar, find me a free hour next week, and book a meeting when I ask. The dishwasher of AI: boring on paper, life-changing in practice.

Budget: zero dollars on inference.

The stack I ended up with:

• Friday, the source-available agent harness I’m building, as the host

• OpenRouter as the LLM provider on its free tier

• A free model that calls tools well (more on picking one in a minute, because this is the part that matters)

• Friday’s bundled Google Calendar MCP as the tool layer

Total ongoing cost: $0. Setup cost: $10 once, which I’ll explain in a second. The $10 sits there. You don’t spend it.

What’s missing from the list: a specific model. I left it out on purpose. The free-model landscape shifts every week; any model I prescribe here will be wrong by the time you read this. So I’ll tell you what worked for me, and then I’ll show you the method for picking your own.

Step 1: Get Friday running

Friday is a source-available agent harness with the boring parts already wired up: settings for swapping LLM providers, a one-click MCP catalog for connecting your Google apps, and a job scheduler for cron-style tasks (which turn out to be the killer app here).

Install instructions live at docs.hellofriday.ai/getting-started/quickstart. Everything runs locally. There’s no Friday cloud to sign up for.

Step 2: Get an OpenRouter API key

OpenRouter is a meta-provider: one API, dozens of model providers behind it. They run a free tier with real models on it.

Head to openrouter.ai and sign up with email, Google, or GitHub. Whatever you have.

Go to Keys in the left nav and create one. Copy the key somewhere safe. You only see it once.

A note on rate limits, because this is where “free” gets nuanced:

• Free tier, no credits: 50 requests per day. That sounds fine until one real agent conversation eats 5 to 10 requests. You’ll burn 50/day in three actual interactions.

• Free tier, after a one-time $10 deposit: 1000 requests per day. The $10 sits in your account untouched. You’re calling :free models, so nothing gets debited. It’s a one-time entry fee.

So yes, my “$0” experiment cost $10. I’m filing it as a deposit, since you never spend the money, and I’ll die on that hill. If you want to use free models for real work, budget the $10. That’s the unlock.

Step 3: Wire OpenRouter into Friday

Open Friday’s settings. Paste the key. Pick OpenRouter as your provider.

Friday has four model roles: classifier, planner, conversational, and validator. You can route all four to OpenRouter for the maximum-free setup, or mix and match. I run all four through OpenRouter, on a single model I picked after a deliberate sweep.

One note: OpenRouter is a first-class provider in Friday now, with the OAuth and base-URL plumbing pre-wired. It wasn’t when I started this experiment. I’ll get to why below.

Step 4: Sweep a few models and pick the one that fits

Public benchmarks don’t catch this, and I’d rather teach you the method than hand you a name.

The free-model market moves fast. New OpenRouter :free models drop monthly. Providers change rate limits. Tool-calling support gets tightened in a model card update you didn’t notice. Any specific “best model” recommendation in a blog post is half-stale the day it ships. So instead of naming a model, I’ll tell you what to look for and how to find the one that fits your workload right now.

Tool-calling is the bottleneck.

The instinct when picking a free model is to look at MMLU scores or general capability rankings and grab whatever sits at the top. That’s the wrong instinct. For an agent, raw capability isn’t what limits you; tool-calling quality is. A “smart” model that writes beautiful prose but can’t emit the JSON to call calendar.create_event is useless. A dumber model that gets the tool calls right beats it every time.

What you’re testing for: given a tool, does the model call it? With the right arguments? Once, instead of in a loop? Does it stop when it’s done?

How to sweep, in about an hour:

1. Browse OpenRouter’s :free model catalog. Pick five or six candidates and vary the families: a Llama, a Qwen, an NVIDIA, a GLM, a MiniMax, whatever’s listed.

2. Plug each into Friday’s settings in turn.

3. Run the same realistic prompt against each. Something like “find me a free hour next week and book a meeting with [person].” Skip toy prompts. You want the model to fail the way it will fail in real use.

4. Watch for the failure modes that disqualify a model. Suggesting a Python script in place of a tool call. Looping on tool discovery without invoking one. Hallucinating arguments. Refusing to commit. Timing out mid-multi-step.

5. Pick the one that finishes the job end to end. Note the runner-up so you have a fallback when your favorite gets rate-limited or deprecated.

A snapshot from when I did this sweep (use it as a vibe-check on the failure modes, no more):

• Llama variants on Groq. Fast. Tool calling was hit-or-miss. Sometimes the right MCP tool got called. Sometimes the model suggested I run a Python script. I don’t have a Python REPL plugged in. That isn’t the thing.

• gpt-oss (20b / 120b). Okay-ish reasoning, weak tool selection. Would discover the tool list, think about it, do nothing.

• Qwen3 free variants. Decent for their size, but they looped. Discover tools, list tools, discuss tools, never call tools.

• MiniMax. Interesting outputs. Kept getting confused about argument shapes.

• GLM-4.5-air. Closer to working, but rate-limited me before I could judge.

• NVIDIA Nemotron-3-Super-120b-a12b. The one that completed a full agent loop end-to-end on my Calendar the day I tested. So that’s what I run today.

Will Nemotron still win when you read this? No idea. Run the sweep. Pick what works. Switch when something better shows up; the cost of switching is one settings change.

The lesson that doesn’t go stale: test tool-calling before you fall in love with a benchmark score.

Step 5: Plug in Google Calendar

Friday ships a bundled Google Calendar MCP server. Open the MCP catalog, find it, add credential under Connections tab. OAuth happens once.

You can flip the same switch for Gmail, Drive, Docs, and Sheets, with the same auth dance and no extra setup.

That’s it. You now have an LLM with hands on your calendar, running on $0 of recurring spend.

Or just ask Friday to do all of this for you!

What it looks like in practice

A real conversation I had with this setup:

Me: Hi, I need to find a free slot for pair programming next week with Michal! Can you check my Google Calendar and show some propositions?

Nemotron read my calendar and came back with a clean day-by-day table of free hour-long windows. A structured suggestion I could look at and pick from.

Me: Can you create that event for Monday then? 14–15 sounds great.

It created the event. A real Google Calendar link came back in the response. The event is sitting in my actual calendar as I write this.

A couple of bumps along the way

Two things didn’t work out of the box. Both are fixed now in Friday. I’m calling them out because the lessons generalize if you’re building agent infra.

I’d built complete() around Claude by accident. Friday auto-injects a complete() tool into every agent so the model can signal “I’m done, here’s the final answer.” The schema I’d written for it was loose. Claude could intuit what I meant; every other model fumbled it, with wrong shapes, missing fields, hallucinated parameters. Tightening the schema (strict mode, recursive additionalProperties: false, forced tool choice) made the entire free-model landscape viable. The same model that returned garbage on Tuesday returned clean structured output on Thursday.

OpenRouter wasn’t a first-class provider. Now it is. Pre-wired base URL, OAuth-compatible token handling, the works. You can use the recipe above without thinking about it. I had to add it to get here.

If you’re building your own agent stack: test against at least three providers from day one. Anything you tune by vibes for one vendor’s quirks will bite you the moment someone else tries it. Mine bit me. I patched it.

The catch: it’s slow

Free is slow. Each multi-step turn with Nemotron on the free tier takes 2 to 5 minutes. You ask, you go make tea, you come back, and maybe it’s done.

Some of that is free-tier queueing. You’re behind everyone else exploring the same idea. Some is the framework: verbose system prompts, agent loops that re-send context every step, MCP tool descriptions that cost tokens. Some is the model itself, thinking out loud before it commits to a tool call.

If you imagined a snappy realtime chat assistant when you read “$0 personal AI,” reset the expectation. The $0 stack runs on a different clock.

The pivot: free AI belongs in cron

The moment I stopped trying to use this thing like a paid chatbot, I understood what it was for.

Free, slow, capable-of-tool-calling AI is perfect for scheduled tasks. Work you submit and walk away from. Output you read.

A few I have running right now, all on $0:

• Friday morning calendar digest. Runs at 8am, summarizes my week, drops it into a note. Takes four minutes. I never notice, because I’m not waiting for it.

• Inbox triage. Runs every few hours, flags things that look like they need a reply by EOD. I read the summary instead of scrolling the inbox.

• Weekly deep-work scheduler. Looks at next week’s calendar, finds a 3-hour block, books it as “focus time.” If it’s wrong, I move it. If it’s right, I get the hours back.

These are the use cases personal AI was supposed to be about. Mundane, useful, the kind of thing that adds up while you weren’t paying attention.

Friday has a built-in job scheduler for this. You define a task in YAML, point it at your model and tools, give it a cron expression, walk away. The 2-to-5-minute latency that makes the setup feel sluggish in chat goes invisible when the task runs while you sleep.

If you’d told me last month my personal AI assistant would run as a cron job, for free, I’d have laughed. It does, and the meetings show up on my calendar.

What this changed for me

I started this experiment thinking the question was “is free AI good enough?” Wrong question.

The right question, the one I didn’t see coming, was “what kind of AI experience do I want?” Once I stopped trying to make free models behave like a cheap knockoff of the paid stuff, I reframed the whole problem. I’m running a slow, patient employee who does the work while I sleep and leaves the result on my desk in the morning. That’s what I wanted all along. I’d been calling it a chatbot.

The other shift took longer to notice. I used to read those AI rationing stories (Uber done by Q2, Pro users hitting their weekly caps mid-week) and feel a low hum of dread, like the future was getting handed out by quota. The dread is gone. The shortage hasn’t gone away; what changed is that a counter-example sits on my own machine now, slow and useful and free. The expensive stuff still works. I just don’t need it to run my week.

Here are 6 ways data and analytics teams are using AI automation to take back their time.

1. Competitive and Market Intelligence on Autopilot

Someone on your team opens ten browser tabs every Monday, skims competitor sites, checks G2, reads two analyst reports, and writes a summary that’s already a week out of date by the time it lands in Slack.

Friday monitors competitor websites, review platforms, news feeds, and LinkedIn pages on a daily schedule. Pricing changes, new feature announcements, positioning pivots: all flagged the same day with a plain-English summary. Friday stores findings across sessions, so instead of re-running searches you can ask “what changed with Competitor X this month?” and get a synthesized answer from everything it’s tracked.

One team we know runs this daily and feeds the output into a competitive Slack channel. Their sales team stopped asking marketing for updated battlecards, and instead read the channel.

2. Scheduled Data Reporting Without a Dashboard

Finance wants a Stripe number. The CEO wants pipeline from HubSpot. The data team wants a Snowflake query result. Someone pulls it manually every Monday morning.

Friday connects to Snowflake, Postgres, SQLite, and HubSpot. You configure the query or the data pull once. Friday runs it on schedule, compares against the prior period, and writes a plain-English summary with the numbers that moved. If a metric crosses a threshold you’ve defined (MRR down 5% week-over-week, conversion rate below a set floor), Friday alerts the right person the day it happens, not at the next scheduled review.

Setup takes about 20 minutes. The Monday morning data pull runs itself after that.

3. Research Synthesis Before Big Decisions

Before a pricing change, a new market entry, or a budget decision, someone spends half a day reading reports, pulling numbers, and writing a summary that most attendees skim. Friday compresses that to minutes.

Give it a question (“What’s the state of AI adoption in mid-market finance?”) and it runs multi-source web research, pulls the most relevant findings, and produces a structured briefing with citations. Paste in customer interview transcripts or survey responses and it clusters themes, surfaces the strongest quotes, and produces a one-page summary. The finished artifact goes to Google Docs or Notion, landing in the workflow your team already uses.

The analyst writes the recommendation and Friday assembles the evidence.

4. CRM and Data Quality Audits

HubSpot has 12,000 contacts and nobody knows which ones are clean. Missing industries, stale lifecycle stages, duplicate companies: every segmentation exercise starts with a manual cleanup job first.

Friday can run a weekly audit, flagging contacts missing required fields, identifying companies with no associated contacts, and surfacing deals with no activity in the past 30 days. The results arrive as a prioritized Slack message with enough context for a sales ops person to act on it in an hour. You can extend it to auto-enrich flagged contacts using web research, finding company size and industry for incomplete records and queuing them for review before writing anything back.

One analyst we know runs this every Sunday night. Monday morning the team has a clean working list. Before Friday, that cleanup happened quarterly, if at all.

5. Multi-Agent Content and Analysis Pipelines

This one came from an analyst who was tired of running the same five-step research process manually every time a new briefing request came in. Here’s the workflow they built in Friday:

A research agent pulls source material and competitor context. That feeds a summarization agent that distills key findings. A scoring agent evaluates the output against a set of criteria: depth relative to the request, coverage of counterarguments, freshness of sources. Each criterion gets a specific note on what’s pulling it down. The output goes back for revision, then hits a final check before landing in Notion for review.

The whole loop runs without a human until the finished briefing appears. By the time the analyst looks at it, the piece has been evaluated and revised against explicit criteria. They edit for judgment, not structure.

This takes about 45 minutes to wire up the first time. After that it runs on every new brief you feed it.

6. AI Tools for Data Governance and Anomaly Alerting

Anomalies in production data often go unnoticed until someone downstream flags a number that looks wrong. By then the bad data has propagated into three dashboards and a board slide.

Friday monitors your key data sources on a schedule. You define what “normal” looks like: acceptable ranges, expected row counts, join rates that shouldn’t drop below a threshold. When something falls outside those bounds, Friday posts a Slack alert with context: which table, which metric, how far off, and a plain-English note on what to look at first. For recurring issues, it builds a running log so patterns become visible across weeks, not just individual events.

One data team we know caught a broken ETL pipeline 40 minutes after it failed because Friday flagged the row count drop before anyone opened a dashboard.

How to Get Started in Friday Studio

None of these require a developer or a lengthy setup. Download Friday Studio, describe what you want it to do in plain English via chat. Friday will connect the tools you already use (Snowflake, HubSpot, Slack, Google Docs, Notion), ask a few questions, and configure your workflow. Most of the setups above take under 30 minutes to run the first time.

Download Friday Studio free at hellofriday.ai or browse the source on GitHub.

It Starts With a Single Prompt

The whole workspace was created from this:

“Setup a workspace to check the surf report for the San Diego area every 30 minutes. Only notify me if there are good surf conditions. Any beach in a 20 mile area is fine.”

Friday handled the rest — creating the workspace, figuring out the right signal provider, wiring the agents, and publishing the config. Here’s what it built.

The Architecture

1. A cron signal fires every 30 minutes

2. A web agent (surf-checker) scrapes Surfline and Magic Seaweed for conditions across ~10 San Diego beaches from Ocean Beach up to Oceanside

3. An LLM evaluator (surf-evaluator) applies real surf criteria and decides whether to alert — no spam, no noise

4. A memory write surfaces the alert in the Friday workspace chat when conditions are good

How Friday Wired the Cron Signal

Friday discovered during setup that the signal provider isn’t called cron — it’s schedule. This is the kind of thing that would cost you 20 minutes hunting docs. Friday found the right schema by probing the API directly and self-correcting:

Fires every 30 minutes. Done.

The Surf Checker Agent

This is a type: atlas agent wrapping Friday’s built-in web bundled agent. Friday wrote the prompt itself from the original request:

Search for current surf conditions at San Diego area beaches within a 20-mile radius. Check Surfline, Magic Seaweed, or similar surf forecast sites. Look at beaches including: Ocean Beach, Mission Beach, Pacific Beach, La Jolla Shores, Del Mar, Solana Beach, Encinitas (Swamis), Carlsbad, and Oceanside. For each beach with notable conditions, extract: wave height, wave period, wind speed and direction, swell direction, and current tide.

The agent opens a real browser, reads the live forecast sites, and returns a structured summary. No API keys needed for Surfline — it just reads the page.

The Evaluator Agent (the Smart Part)

This is where most surf alert systems fall apart. They either spam you with 1-foot junk or require you to tune a dozen thresholds. Friday wrote the surf-evaluator as an llm agent with a clear, explicit rubric derived from “good surf conditions”:

Good conditions (trigger alert):

• Wave height 3 ft or larger

• Wave period 8 seconds or longer (cleaner, more powerful waves)

• Wind offshore or light (under 10 mph)

• Swell from NW, W, or SW — the good angles for San Diego beaches

Poor conditions (stay quiet):

• Under 2 feet

• Choppy onshore wind above 15 mph

• Short-period wind swell under 7 seconds

If conditions are good at any beach, it writes a SURF ALERT to long-term memory with the beach name, stats, and a one-sentence recommendation. If conditions are poor, it logs a quiet one-liner to the notes store and moves on.

What a Surf Alert Looks Like

When conditions meet the threshold, the evaluator writes something like:

SURF ALERT: Swamis (Encinitas) looking clean — 4–5 ft @ 12s, NW swell, light offshore wind under 8 mph. Head out before 10am before the sea breeze kicks in.

When conditions are poor, you get nothing. That silence is the feature.

One Thing to Know About Notifications

Wire a Telegram communicator and the alerts land directly in your phone. Here’s what an actual alert looks like:

Four beaches, current conditions, best window, and a link to Surfline — all from a single scheduled job.

Why This Works Well

Judgment belongs in the agent, not the config. Rather than encoding “good surf” as a brittle rule in a scheduler, the criteria are described in plain English and evaluated by an LLM on each run. It understands context — 3 ft at 6 seconds feels worse than 2 ft at 12 seconds.

Real browser access. Surf forecast sites are JavaScript-heavy. The web agent runs a real browser, so it reads Surfline exactly as a human would — no scraping brittle HTML, no API fees.

Signal-first design. The cron signal is the clock. The job is the logic. Changing the schedule is a one-line edit. Adding a second job that texts instead of logging memory is additive, not a rewrite.

The Full Workspace YAML

This is the shareable config that Friday generated from the chat — you can drop this into any Friday instance to recreate the workspace exactly:

version: ‘1.0’
workspace:
  name: San Diego Surf Watch
  description: Monitors San Diego area surf conditions every 30 minutes and notifies when conditions are good.

signals:
  surf-check-cron:
    provider: schedule
    description: Fires every 30 minutes to check San Diego surf conditions
    config:
      schedule: “*/30 * * * *”agents:
  surf-checker:
    type: atlas
    agent: web
    description: Fetches current surf conditions for San Diego area beaches within 20 miles
    prompt: >-
      Search for current surf conditions at San Diego area beaches within a
      20-mile radius. Check Surfline, Magic Seaweed, or similar surf forecast
      sites. Look at beaches including: Ocean Beach, Mission Beach, Pacific
      Beach, La Jolla Shores, Del Mar, Solana Beach, Encinitas (Swamis),
      Carlsbad, and Oceanside. For each beach with notable conditions, extract:
      wave height, wave period, wind speed and direction, swell direction, and
      current tide. Return a structured summary. Focus on accuracy.  surf-evaluator:
    type: llm
    description: Evaluates surf conditions and saves a surf alert to memory if conditions are good
    config:
      provider: anthropic
      model: claude-sonnet-4-5
      prompt: >-
        You are a surf conditions analyst for San Diego.
        Evaluate the surf report. Good conditions: 3ft+, 8s+ period, light/offshore wind, NW/W/SW swell.
        If good: call save_memory_entry (memoryName=”memory”) with a SURF ALERT.
        If poor: call save_memory_entry (memoryName=”notes”) with a one-line log.
        Always call save_memory_entry exactly once.jobs:
  surf-watch:
    description: Checks San Diego surf conditions every 30 min and notifies if surf is good
    triggers:
      - signal: surf-check-cron
    execution:
      agents:
        - surf-checker
        - surf-evaluatormemory:
  own:
    - name: notes
      type: short_term
      strategy: narrative
    - name: memory
      type: long_term
      strategy: narrative

Try It Yourself

The setup above works for any location. Swap out the beach list and surf criteria for your local break. The same pattern — schedule signal → web scraper → LLM evaluator → memory alert — works for weather windows, tide charts, or any real-world condition you want to monitor without babysitting a dashboard.

Download Friday Studio free at hellofriday.ai or browse the source on GitHub.

1. Automated Content Briefing from Slack to Google Docs

A content manager types a campaign idea into Slack. By the time they open Google Docs, the brief is already there: target audience, keyword angles, competitive references, and a suggested outline. Without Friday Studio, that brief takes 30 to 45 minutes to assemble from four different browser tabs.

Friday Studio connects a Slack signal to a pipeline job that runs a web research agent, pulls competitor content with the web bundled agent, and writes the finished brief into Google Docs via the Google Docs MCP server. The content manager reviews it, adjusts one or two lines, and hands it to the writer. The research leg of the job disappears entirely.

2. AI Marketing Performance Summaries on a Weekly Schedule

Performance reporting is the task marketing teams do every week and dread every week. Someone pulls numbers from the CRM, cross-references campaign data, writes a summary paragraph, formats a table, and sends the Slack post. For a small team, that is two hours of work producing a document most people skim.

Friday Studio runs a scheduled job every Monday morning. A schedule signal fires at 8am, a pipeline agent queries HubSpot for deal and contact activity via the bundled hubspot agent, and an llm agent writes a plain-language summary covering open pipeline movement, new contacts created, and campaign-attributed activity. The finished report goes to a Slack channel via the bundled slack agent. The marketing manager reads it over coffee and spends the hour on something else.

3. AI Lead Generation: Routing Inbound Leads to HubSpot

Inbound leads from web forms, demo requests, and event sign-ups pile up in a spreadsheet or a shared inbox. Someone checks it each morning, manually creates the HubSpot contact, writes a note, assigns the lead to a rep, and sends a confirmation email. When the team is in back-to-back meetings, that process waits until afternoon.

Friday Studio listens for new leads via an http webhook signal. Each time a form submission arrives, a pipeline job runs: a user agent parses the payload, the hubspot bundled agent creates the contact and attaches deal and source data, and the google-gmail MCP server sends a confirmation email to the prospect. The rep gets a Slack DM with the contact summary. The whole loop closes in under a minute without anyone touching a keyboard.

4. Campaign Brief Distribution Across Notion and Google Drive

When a campaign kicks off, the marketing lead writes one brief and then copies pieces of it into Notion for the design team, Google Drive for the agency, and a Slack message for the paid media team. Keeping three versions in sync through rounds of revision costs more time than writing the brief itself.

Friday Studio handles distribution through a single pipeline job triggered by an http webhook when the source brief is finalized. An llm agent reads the master document from Google Drive via the Google Drive MCP server, reformats sections for each audience, writes the design-facing version to Notion via the Notion MCP server, saves the agency version to a Google Drive folder, and posts a summary to the Slack channel. The brief lives in one place; Friday keeps the downstream copies current.

5. Content Repurposing from Blog Posts, Webinars, and Interviews

A webinar recording, a long-form blog post, a customer interview: each one contains enough material for a month of content. Most teams publish it once and move on, not because they don’t want the LinkedIn posts and newsletter excerpts, but because producing them takes another hour no one has.

Friday Studio runs a repurposing job triggered by an http webhook from your CMS, an fs-watch signal on your drafts folder, or manually from chat. An llm agent reads the source: a finished blog post via Google Drive, a webinar transcript pasted in or fetched via URL, a Fathom call recording pulled with the bundled fathom-ai agent. From that single input, it generates the derivative set: a LinkedIn post formatted for the professional context, a short newsletter excerpt with narrative arc, a punchy thread, and a subject line variant. Each version lands in a Google Doc for review.

One content manager we know runs this on every webinar their team produces. They paste the transcript link into Slack, Friday picks it up via a Slack signal, and the derivative drafts are ready before the recording finishes uploading. They spend 10 minutes editing instead of 90 minutes writing from scratch.

6. Post-Campaign Summarization from Call Transcripts

After a product launch or a campaign with customer interviews, someone has to turn 10 Fathom call transcripts into a summary: key objections, messaging that resonated, themes for the next cycle. It usually falls to the most senior person on the team and takes a full afternoon.

Friday Studio pulls the transcripts using the bundled fathom-ai agent, which fetches call data by date range or by tag. An llm agent reads all the transcripts, clusters recurring themes, extracts notable quotes, and writes a structured summary with sections for objections, positive signals, and open questions. The finished document goes to Google Docs via the MCP server and a link drops in the team Slack channel. The debrief that used to take a half-day takes 10 minutes to review.

How to Get Started

None of these require a developer or a day of setup. Download Friday Studio, describe the workflow you want in plain English via chat, and Friday will ask a few clarifying questions before wiring up the tools you already use. Most of the workflows above come together in under 30 minutes. The HubSpot and Slack connections are zero-config with the bundled agents. Gmail, Notion, Google Drive, and Google Docs connect through MCP servers that take a few minutes to authorize.

The fastest starting point for a marketing team is the weekly performance report. It touches tools you already have, produces something you already need, and gives you a working example to build from.

Download Friday Studio free at hellofriday.ai or browse the source on GitHub.

Here are 6 use cases you can use as a sales professional to close more deals, keep your pipeline full, and stay top of mind to win business.

1. Keeping a Network Warm at Scale

Your best deals come from warm relationships: people who already know you, trust you, and think of you when the right moment arrives. Maintaining that across thousand-person networks is impossible to do by hand. So most people don’t, and the network goes cold.

Friday tracks a list of contacts you care about (investors, partners, past colleagues, potential clients) and monitors their public activity: LinkedIn posts, company news, funding announcements, job changes. When something relevant happens, Friday surfaces it with a short note on why it’s worth reaching out and drafts a personalized message for each trigger: congratulating someone on a promotion, referencing a post they published, following up after a conference they spoke at. The message reflects your voice because you define the tone once and Friday applies it every time.

It also runs a weekly check: who haven’t you been in touch with in 60+ days? Friday flags the list and queues draft messages. Staying in contact becomes a 20-minute review session instead of something you intend to do and never get to.

One founder we know runs this across a 3,000-person network. They spend about 15 minutes each workday reviewing and sending three messages. Before Friday, that network was largely dormant.

2. Sourcing Leads Against a Specific Target Profile

Finding companies that fit your ICP takes hours of Googling, LinkedIn searching, and cross-referencing. Most of the time it produces a messy spreadsheet that half the team ignores because the effort to build it wasn’t worth it.

You define the criteria: industry, company size, geography, funding stage, tech stack, headcount growth, any signal that defines a good fit. Friday searches and scrapes across public sources to build a list of matching companies, enriched with what you need: website, key contacts, recent news, and the specific signal that flagged them.

For each company, Friday drafts a first-touch message in your inbox referencing something specific (a recent hire, a funding round, a product launch) so the outreach doesn’t read like a template blast. It runs on a schedule. Every week, or at a cadence you choose, Friday adds companies that newly entered your target profile and queues them for review. Your pipeline fills with companies that fit, and the outreach goes out when the signal is fresh.

3. Deal Intelligence and CRM Hygiene

After every sales call, Friday reads the transcript (from Gong, Fireflies, or a pasted summary), extracts next steps, objections, and deal signals, and writes structured notes directly into HubSpot. No post-call data entry required.

It then monitors your pipeline daily: flags deals that haven’t moved in 7+ days, identifies at-risk accounts by scanning email threads and call notes for warning signs, and surfaces them in a Slack digest every morning. When a deal closes, Friday generates the CS handoff brief (contract details, key stakeholders, stated goals) automatically.

Reps spend less time on admin, pipeline data stays current, and customer success onboarding starts with context rather than a blank page. You also get the added benefit of a cleaner handoff between rep and account manager.

4. Pre-Call Research Briefs

A good discovery call requires knowing who you’re talking to. Most reps have five minutes between their last meeting and the next one.

The night before, or an hour before, Friday researches the company and the contacts on the call: recent funding, product changes, leadership hires, tech stack signals, and any press coverage worth referencing. It produces a one-page brief with the three most relevant talking points and the questions most likely to open the conversation. You can have it pull prior interaction history from your CRM (previous calls, email threads, notes from earlier deals), your notes app, email, or any other data source, so you get full context on who you’re speaking with.

The brief arrives in Slack or email at a scheduled time. The rep doesn’t have to trigger anything.

5. Proposal Research and Personalization

Most proposals fail to land because they’re generic. The pricing is right, the features match, but nothing in the document shows you actually understand the buyer’s situation. Friday fixes the research half of that problem.

Before you send a proposal, Friday researches the prospect’s business in depth: their current tech stack from job postings and public profiles, recent hires that signal a strategic priority, budget signals from headcount growth or funding news, and any public statements from their leadership about what they’re trying to accomplish. It then produces a one-pager of what to weave into the proposal: the specific pain points to reference, the language their team uses, the angles most likely to resonate with the person signing off. You can even connect a Google Slides MCP and have Friday build a custom deck based on your existing templates, scheduled around your meetings for the week.

6. Win/Loss Pattern Analysis

Most reps have intuitions about why deals close or die. Few can prove them. Friday reads through all the call notes, objections, and outcomes logged in HubSpot and surfaces the actual patterns: which objections correlate with closed-lost, which industries close fastest, which personas stall at procurement, which competitors keep showing up in deals that go sideways.

Run it quarterly and you get a plain-English summary of what’s working and what’s not, grounded in your own deal history rather than generic sales advice. The rep who lost three enterprise deals to the same competitor this quarter finds out before the fourth one, not at the annual review.

How to Get Started in Friday Studio

None of these require a developer or a lengthy setup. Download Friday Studio, describe what you want it to do in plain English via chat. Friday will connect the tools you already use (HubSpot, Slack, Gmail, LinkedIn), ask a few questions, and set up your workflow. Most of the workflows above take under 30 minutes to configure the first time.

Download Friday Studio free at hellofriday.ai or browse the source on GitHub.

There’s a growing category of purpose-built tools for AI-generated 2D game assets: tile generators, sprite-sheet exporters, and style-locked models fine-tuned on pixel art. They’re impressive, but often unnecessary.

If you already use an AI workflow automation system, you likely have everything you need to replicate the core idea. A pipeline is just a sequence of prompts, transformations, and file operations. You don’t need a wrapper product to get the benefits.

What the Specialized Tools Are Actually Doing

Strip away the UI and the marketing, and most 2D asset tools follow the same playbook:

1. Accept a prompt or reference image.

2. Run it through a generative model with a constrained style.

3. Post-process the output (resize, crop, remove background, export to a sprite-sheet format).

4. Optionally generate variants like rotations, palettes, or animation frames.

All of this is composable in a general automation system. Image generation APIs are widely available. Background removal is one tool call. File transformation is a short script. The “magic” is mostly orchestration, and orchestration is exactly what automation is for.

Where It Actually Gets Hard

There are two genuinely difficult problems with AI-generated game assets. Not “you need a specialized product” difficult, but “this takes real thinking to solve” difficult.

1) Transparency: the alpha channel problem

Generative image models produce JPEGs in their heads. Even when they output PNGs, they rarely produce clean transparency. Characters sit on white or gray backdrops. Shadows bleed into floors. The sprite looks fine in a preview and wrong the moment you drop it into a game.

The fix is usually some combination of background removal (chroma key, segmentation, or a dedicated removal API) followed by alpha cleanup. None of this is conceptually hard, but it adds a non-trivial step to every asset, and quality can be inconsistent, especially around fine edges like hair, feathers, or busy outlines.

If your pipeline doesn’t handle this upfront, “generate asset” quickly becomes “generate asset + manual cleanup.”

2) Consistency: the animation frame problem

Single images from a model can look great in isolation. Ask the same model for the next frame of a walk cycle and you may get a character who has quietly changed their shoes, armor color, and jaw shape.

This is the deeper issue: most models don’t reliably preserve identity across generations. Every frame is effectively drawn from scratch, and consistency depends on how tightly your prompt, seed, and conditioning constrain the output. In practice, those constraints are rarely tight enough for fluid animation, especially for anything more complex than a simple loop.

Approaches that reduce inconsistency:

• Reference-image conditioning: feed the first frame back in as an image input for subsequent generations. This narrows variance significantly, but doesn’t eliminate it.

• ControlNet-style pose conditioning: lock the pose across frames and let the model fill in appearance. This requires a model that supports pose/control inputs.

• Frame interpolation as a last step: generate keyframes and interpolate between them rather than generating every frame. You trade some control for smoother continuity.

• Accept variance and design around it: some styles (hand-drawn, deliberately jittery) tolerate or even benefit from inconsistency. Not always viable, but worth considering.

None of these are complete solutions; they’re mitigations. Consistency is still the reason many shipped games using AI-generated assets either feel slightly “off” in motion or hide the issue with short loops and clever masking.

What This Means in Practice

You can get a lot of value from agent orchestration without reaching for specialized tools. An asset pipeline is just one example: background removal, variant generation, sprite-sheet export, style checks, and all of it can live inside a single workflow system.

Once the pipeline exists, extending it to other parts of your production process becomes straightforward. That’s the actual advantage: not automating one step, but having one place to automate everything.

I built this pipeline in Friday Studio. You can use it to wire up the same asset generation, background removal, and sprite-sheet export without adding another tool to your stack. Try it for free at hellofriday.ai.

After too many late-night retries, I stumbled on an unlikely mentor: my two-year-old son. Guiding him through language, blocks, and the fine art of tying your shoes showed me a better way to guide a large language model.

Parenting, it turns out, is an ideal blueprint for co-programming with AI.

From one shot frustration to gentle parenting

Looking back, my early workflow mirrored an anxious new parent who expects a toddler to nail every developmental milestone on the first try. I agonized over phrasing, fired a single request at the model, and binned the code when it hiccupped. It worked eventually. But it was slow going trying to code this way, and worst of all: it wasn’t very fun.

Those failures weren’t the model’s fault. They were mine. I was withholding feedback, the raw fuel any learner needs. When my son tries a new word and doesn’t quite nail the pronunciation, I don’t shove a dictionary at him and walk away. I correct the syllable and let him know once he gets it right, praising him for making the effort the whole time. Software, surprisingly, responds to the same gentle course-correction.

I began treating the AI like a curious kid: expect missteps, correct them quickly, and capture the lesson. The change felt small — just a tweak in tone — but the impact was huge.

Now, when the assistant misuses an SDK or confuses an auth flow, I don’t scrap the session. I say, “Good try. Here’s the mistake. Please fix it and write a rule so you never repeat it.” The model answers with a short markdown file of self-authored guidelines, stores it, and re-reads those guardrails on the next task.

This isn’t real learning in the neurological sense; it’s closer to taping a reminder note on the fridge. But the illusion of memory is enough. My toddler doesn’t actually memorize every correction either. He recalls patterns because we practice them in context. The assistant does the same, consulting its growing rulebook whenever I call for a new snippet.

At first the model needed lots of nudges — just like my son asking “Why?” ten times in a row. But a funny thing happened as the rulebook thickened: output quality leapt.

Why? Because each tiny correction removed an entire class of future failure. Once the assistant understood things like why a JSON tag must match a struct field, it stopped guessing. Those lessons compounded until I could “one-shot” a feature again, this time with confidence it would pass unit tests.

Why iterative feedback beats perfectionism

This parenting-inspired loop does more than save keystrokes; it reshapes the developer’s job. I used to spend 60 percent of my time typing and 40 percent thinking about product and architecture. With an assistant that iterates in seconds, the typing portion is shrinking to zero. That frees me to refine specs, design cleaner APIs, and chase the “taste” questions no model can answer — Does this feel good? Is it delightful?

Speed matters outside my IDE as well. When a team can validate an idea in the first 10 percent of the schedule instead of the last 60 percent, product risk plummets. You ship fewer “first pancakes” and spend more cycles on flavor instead of raw batter.

Practical steps to raise your AI right

A quick recap, distilled into parent-tested habits you can start today:

1. Expect mistakes and plan for them. Open every session assuming the first draft will wobble. That mindset removes frustration and primes you to give constructive feedback.

2. Correct, don’t restart. Highlight the single error, explain why it’s wrong, and ask the model to fix it. Once the fix is working, have it document what it did with and generate a rule prohibiting that mistake. Treat retries like practice reps, not new games.

3. Store the rulebook close to the code. I keep the markdown file in the project root where the assistant can “read” it before generating anything new. The proximity reinforces good habits.

4. Automate the yardstick. Pair the rules with unit tests, linters, or type checks so the assistant sees objective pass/fail signals without waiting for you. Kids learn faster when they get instant feedback; models do too.

5. Celebrate small wins. When the assistant nails a tricky compile or cleans up ESLint errors on its own, give positive reinforcement. It may seem weird, but there’s some evidence to suggest that politeness and encouragement lead to better outputs. A quick “Great job — run the full suite next” can boost compliance in subtle ways.

Adopt these five and you’ll notice the ratio of supervision to autonomy tilting in your favor.

Beyond coding: the human payoff

The parallel goes deeper than productivity metrics. Parenting teaches patience, empathy, and the art of breaking complex ideas into bite-sized lessons. Those same skills make you a better teammate. Colleagues who struggle with tooling often need the identical approach: clear examples, immediate feedback, and guardrails that let them explore safely.

An AI assistant, used this way, becomes a rehearsal space for leadership. You practice giving precise instructions, spotting root causes, and nudging rather than dictating. The machine never rolls its eyes, so you can iterate on your communication style until it lands with real humans.

Closing the loop

My son still struggles sometimes, and the AI still forgets an edge case now and then. But our household — and my codebase — runs smoother because I stopped demanding perfection and started teaching process. Children thrive on secure boundaries and consistent feedback. So do language models. Treat your AI like a toddler who wants to help, and you’ll get cleaner commits, faster prototypes, and a lot more fun along the way.

In other words: parent your tools, not just your kids. The lessons carry over, and the rewards compound.

We’re building something new. Check it out at hellofriday.ai.

This article was originally published on July 22, 2025 on Medium.

Here’s the catch: I’m not a Golang engineer, I’m a frontend developer, and building the best possible user experience for Tempest is still where I’m putting most of my effort. That means my time was limited, and I couldn’t constantly interrupt my team for help. To succeed, I had to develop a reliable, efficient method for working with AI — one that let me quickly fix mistakes, iterate efficiently, and ship production-ready code despite not being a master Golang hacker.

I want to share exactly how I did it, what I learned along the way, and some tips for anyone else looking to make the most of AI-driven development.

My experience leveraging AI in my day to day work and in my personal projects has taught me that for simple things like building and integrating an API into an app — a not inconsequential subset of the workload in most engineering orgs — AI rewrites the rules. If a good engineer with general knowledge but no language or domain-specific knowledge can nonetheless churn out production-ready code at a pace once reserved for experienced, 10x engineers, the game has changed.

A few caveats

Before I get too carried away with the AI praise, though, I do think it’s important to be very clear about the context. Large Language Models aren’t magic, even though they sometimes feel that way for a subset of tasks. I’m speaking mostly to the engineering managers reading this right now: don’t think that AI means you can buy your frontend org a Cursor subscription and have them refactor the Cobol at the heart of your payments systems. The results I got from working with AI are definitely not generalizable to every possible development task.

But when it works, it really works, and creating integrations in Tempest happens to be particularly well-suited to AI assistance, largely thanks to our robust Golang SDK. This SDK simplifies the task, turning it into a structured translation exercise — something large language models are uniquely suited to.

Moreover, Go itself is ideal for AI development, given its clear, statically typed syntax. Its simplicity reduces ambiguity, helping AI produce accurate, effective code quickly. Additionally, Go’s rapid compiler feedback enables immediate error correction, dramatically speeding up iterations from hours to mere second.

Private apps in Tempest already put a lot of power in developer’s hands without requiring a ton of development overhead. But when you factor in AI, it’s really pretty amazing what you can get done.

My workflow: From concept to production-ready code

Even with a task and a language uniquely suited to AI coding, there’s still a learning curve with these technologies. My initial approach was to treat them sort of like a code dispenser — spend a lot of time writing the prompt, and if it didn’t give me what I wanted, refine the prompt until it did.

But I found that’s not the best strategy. While it’s true clarity, explicitness, and concretely defined requirements are extremely important, and you have to put the work in up front to achieve that in your prompt, a good prompt alone will never get you all the way to your goals. Instead, AI really shines when you use it to iterate on the code itself through rapid cycles with tight feedback loops.

This is the biggest point people miss about AI development. It isn’t so much that the code is always perfect from the moment you generate it. Actually, the first thing you get back is often pretty bad. Even in my case, where I was working with the platonic ideal of an AI vibe coding use case, about half the time the code the AI produced would fail to compile.

However, when you work with an AI coding assistant, it becomes much easier, and much faster, to fix mistakes. What would normally have taken hours to fix took minutes. That means bad code becomes good code crazy fast. Sure, it might take 30 iterations to get your vibe code into a usable state. But if you can do those 30 iterations in half the time it would have taken to produce a single try on your own, that’s still a huge net boost to your overall productivity.

To illustrate exactly how my AI-assisted workflow evolved, let’s consider a hypothetical example: building an integration for Slack using its public API. This use case encapsulates each critical step, highlighting both the process and tools involved.

• Initial Research: First, I’d dive into Slack’s API documentation to understand key elements like channels, messages, and user interactions, the building blocks that I had to work with. Initially, I did this manually, but later realized AI could summarize this and significantly accelerate this phase by sifting through the documentation for me and highlighting just the necessary information.

• Drafting a Clear Product Spec: This step turned out to be absolutely crucial. Rather than vague descriptions, I learned to provide very explicit, detailed specs to the AI, which usually were a couple paragraphs long. I also provided it with one or two examples of what I was looking for — AI sometimes struggles to give you exactly what you need even with a fairly detailed spec, but providing an example radically improves accuracy.

• Generating Initial Code: With the product spec ready, I’d feed it into Cursor, my AI coding assistant. Cursor leveraged the clarity of my spec to generate a nearly complete Go implementation using our Tempest Golang SDK and Slack’s API.

• Quick Manual Review: Before testing, I’d quickly skim through the generated code, checking for any obvious misunderstandings or missing functionality. Given a clear initial spec, this was usually brief.

• Real-World Testing and Iterative Refinement: If the initial code passed the smell test, I’d try to compile it. Often, the first try wouldn’t compile, but Go’s precise compiler feedback allowed rapid identification of errors. I’d feed these specific error messages back into Cursor, prompting it to iterate quickly and automatically fix them.

• Establishing Guardrails: When there was a style error or something simple, I’d explain what was wrong to the AI and have it fix it. Then I’d have it write an explicit rule to follow that addressed the error which I’d include in the system prompt going forward. That way, not just the code I was writing but the AI assistant itself improved over time. By the end, I was getting much cleaner and more compliant code on the first try.

• Final Polishing: Occasionally, there’d be subjective tweaks or enhancements, or user-facing text. I found it was often helpful to tweak this kind of thing manually as a final step, rather than trying to get the AI to generate it. Usually I could fill in what I wanted myself faster than I could figure out how to prompt the assistant to produce it.

By following this structured, iterative cycle with clear, detailed guidance, the AI-generated integration would rapidly evolve from a rough initial draft to polished, production-ready code in minimal time.

A Qualitative Shift in How I Code

One thing that surprised me as I integrated AI into my workflow over the past year was how radically it changed my approach to coding projects. Previously, I often relied heavily on a more improvisational style. I would start with only a vague conception of what I wanted to build, using the act of writing code itself as a way to think through and clarify the details as I went. Typing slowly gave me the space and time to refine my ideas and experiment incrementally.

But AI doesn’t work like that. With AI, clarity isn’t just beneficial; it’s absolutely essential. If you don’t start out with a crystal-clear understanding of what you want, you can’t formulate the precise, detailed prompts AI needs to generate usable code. Without that precision, the initial output is often too far off-base to be quickly corrected.

Consequently, programming with AI becomes intensely frontloaded. Rather than figuring things out as you type, the initial stages of research, conceptualization, and careful planning are now critical. Once you’ve nailed that initial plan, the actual act of coding takes very little time. Likewise, iteration and bug fixing become swift and largely automated, drastically compressing the cycle of development from concept to working prototype.

This new approach changes what it takes to be a successful developer. Creativity and firsthand knowledge of the problem space become far more valuable than deep expertise in any specific programming language. In many ways, this is ideal for front-end developers. We’re typically deeply connected to user experiences and have extensive insight into user desires, behaviors, and common stumbling blocks. Now, we can bring that user-focused understanding to a broader range of development tasks that previously might have been outside our expertise.

I genuinely believe this approach will lead to better products. Instead of getting bogged down by extensive upfront coding efforts or stuck iterating on hypothetical product specifications, we can quickly build and ship actual prototypes. Real-world feedback from live users can then inform rapid, iterative improvements in near real-time. This agile approach means our products are not just more responsive to user needs but also evolve far more quickly.

In short, coding with AI assistance isn’t just about working faster — it’s about coding smarter, more creatively, and ultimately delivering better products.

This article was originally published on June 19, 2025 on Medium.

First, AI systems behave more reliably when they plan work before executing it — when the system understands the steps involved ahead of time, many common failures become easier to avoid.

Second, once agents begin running work across tools and environments, reliability becomes a systems problem. Execution introduces partial failures, evolving context, and coordination challenges that look more like distributed systems than prompts.

Those observations led to a practical question: how should an AI system represent work so it can run reliably over time?

The Code Generation Trap

Our first instinct was the same one many teams have today. We asked the model to generate the system directly.

Large language models are remarkably good at writing code. Give them an example and describe what you want, and they can often produce code that compiles. So our early approach looked straightforward. A user would describe the work they wanted done. The model would generate the TypeScript required to build the workspace and its associated jobs. That code would then execute inside a sandboxed worker environment.

At first, this approach seemed promising. Most of the time, the generated code worked. But the remaining cases quickly became painful. Sometimes the model would hallucinate step identifiers that didn’t exist. Other times it would wrap the generated code in Markdown fences despite being explicitly instructed not to. Small formatting variations would break downstream parsing.

We added retries. If the generated code failed validation, the system would ask the model to regenerate it. Two retries solved many cases, but those retries were hiding a deeper problem.

The system was relying on nondeterministic code generation to produce infrastructure. When your orchestration layer depends on outputs that can vary between runs, debugging becomes extremely difficult. A workspace that works today might generate slightly different code tomorrow.

Eventually we realized something uncomfortable. We were asking the model to do the wrong job.

What Models Are Good At

Large language models excel at certain kinds of problems. They are extremely good at understanding intent — they can classify information, interpret vague instructions, and map human language into structured meaning. But they are not good at producing deterministic infrastructure.

Code generation feels appealing because it gives the model a lot of freedom. But that same freedom introduces the very nondeterminism we were trying to eliminate.

Once we reframed the problem, the architecture started to change. Instead of asking the model to generate the system itself, we began asking it to make decisions about the system. Everything else could be handled by deterministic code.

The Compiler Pattern

This shift led us toward a pattern that looks surprisingly similar to compiler architecture. In a traditional compiler, the front-end parses human input into structured representations. The back-end then transforms those structures into executable code. We applied the same idea to agent orchestration.

The model acts as the front-end. Its job is to understand intent and produce structured data that describes the work. From there, the rest of the system behaves like a compiler — a deterministic pipeline transforms that structured representation into the configuration required to run the workspace.

The model no longer generates infrastructure directly. It generates typed descriptions of what the infrastructure should do. The compiler handles the rest.

Structured Generation

One of the most useful patterns that emerged from this approach was splitting generation into multiple constrained stages.

First, the model generates human-readable job names and descriptions — things language models are naturally good at producing. The system then converts those names into stable identifiers programmatically.

Next, the model generates the relationships between those jobs, but it is constrained by a schema that only allows references to identifiers that already exist. If the model produces an invalid reference, the schema validation fails immediately.

Instead of discovering hallucinated step references during execution, the system catches them during planning. This approach turns what would normally be runtime failures into simple validation errors. In effect, the type system becomes a guardrail around the model’s output.

Parallel Enrichment

Once the system produces a structured blueprint of the workspace, additional analysis can happen in parallel.

Different reasoning passes enrich the workspace plan in different ways. One pass may classify signals or triggers. Another may determine the appropriate agent behavior. A third may analyze how information should flow between jobs.

Because these steps operate on structured data instead of generated code, they can run independently and concurrently. This reduces latency significantly and keeps the pipeline easier to reason about.

The Compiler

At the end of the pipeline sits the compiler itself.

The compiler takes the fully enriched workspace description and deterministically generates the configuration required to execute it. This stage contains no model calls. It is a pure function — the same input always produces the same output.

Because the compiler is deterministic, it becomes easy to test and debug. Workspaces can be inspected before execution, and engineers can reason about the transformation process the same way they would reason about any other piece of software infrastructure.

In many ways, this stage is intentionally boring. And that turns out to be exactly what you want in the part of the system responsible for orchestration.

The Lesson

Looking back, the biggest lesson from this process was surprisingly simple.

Most teams building with large language models are fighting the properties of the tool. They ask models to produce deterministic outputs. They expect them to follow exact syntax. They attempt to prevent hallucinations through instructions alone.

But language models are inherently probabilistic systems. Reliable architectures embrace that fact instead of trying to suppress it.

Models are excellent at understanding ambiguity and making contextual decisions. Traditional software systems are excellent at determinism and execution. The most reliable AI systems combine both — they let models reason about intent, and they let deterministic systems handle everything that requires precision.

That combination turned out to be the key to making agent systems behave reliably.

Check out the first two articles in this series, What Does It Mean for AI to Do Work and Building AI Agent Systems is a Management Problem, or try out Friday AI today.

This article was originally published on March 22, 2026 on Medium.

Planning improves reliability because it allows both the user and the system to understand the work before anything runs.

But planning alone does not solve the hardest problems in agent systems.

Those problems appear once execution begins.

In this article, we look at why building reliable AI agents turns out to be less about prompting and more about system design.

Prompts are not systems

Most early AI tools were built around a very simple interaction model:

• A user writes a prompt.

• The model generates a response.

• The interaction ends.

This works remarkably well for many kinds of tasks. Writing, summarization, research, brainstorming. The model receives a request, produces an output, and the job is done.

Agent systems are different.

Instead of producing a single response, the system is asked to perform work. It might gather information, analyze it, interact with tools, and generate outputs that affect other systems.

Once that begins to happen, the interaction stops looking like a prompt, and it starts looking like a workflow.

And workflows behave much more like software systems than conversations.

Workflows introduce structure

A workflow has properties that a prompt does not.

Steps depend on each other, and subsequent steps may change based on the outcomes of previous ones. Actions may happen across several different tools, in a specific sequence or at the same time. Information produced earlier in the workflow becomes input for later stages.

The system now has to manage state. It has to understand what has already happened and what still needs to happen.

This is where the limitations of prompt-based approaches begin to appear.

If every step of a workflow is treated as a new prompt, the system is constantly reconstructing context. Small misunderstandings can propagate through later actions. Recovering from failures becomes difficult.

The model may still be reasoning correctly, but the structure around it is fragile.

Execution introduces uncertainty

Many, if not all, requests that expect to produce real work will require interaction with tools outside of the control of the AI agent itself. For example, to send an email the system must interact with your email provider. To write and produce code it must interact with a Git repository. To notify a team it may need access to Slack or another messaging system.

And the moment an agent begins interacting with these external systems, the environment becomes unpredictable.

APIs return unexpected responses. Messages arrive later than expected. Data that was present yesterday may not be present today.

Traditional software systems deal with these problems constantly. Engineers design systems that can handle failures, retry operations, and recover from unexpected states.

Agent systems need similar capabilities.

Without them, even well-designed workflows can break down once they encounter the real world. Once multiple tools and reasoning steps are involved, the system needs a way to coordinate them.

Coordination becomes necessary

As workflows grow more capable, they often involve multiple types of reasoning and action.

One part of the system may gather context. Another may analyze information. A third may interact with tools.

Each of these steps depends on the others.

At this point, the agent is no longer just responding to a single prompt, it’s coordinating work across multiple components.

Systems that lack clear coordination mechanisms tend to become brittle, and one small failure or edge case can disrupt and break the entire workflow.

As a result, you need an architecture that’s able to manage that coordination.

What reliable agent systems need

Once we started thinking about agents as systems instead of prompts, the problem became clearer.

Planning helps a system understand work before it begins. But once execution starts, additional challenges appear.

Reliable agent systems need a few core capabilities.

First, work needs durable structure. Tasks should exist as explicit pieces of work that the system can start, pause, retry, or run again without losing context.

Second, systems need clear boundaries between steps. Instead of asking the model to dynamically invent entire workflows, execution should happen in stages where reasoning and actions are easier to observe.

Third, systems need coordination between tasks. Real work rarely happens in a single step. Gathering context, analyzing information, and taking action often need to happen in sequence or in parallel.

Finally, systems need visibility into execution. When something unexpected happens, users should be able to see what the system did and why.

These ideas may sound familiar to anyone who has built distributed systems. The difference is that now the reasoning layer is powered by large language models.

Once we started viewing agent systems through this lens, the architecture became much clearer.

Instead of asking the model to dynamically invent workflows, we built a system where work has structure, execution is coordinated, and behavior is observable.

In the next article, we will walk through the architecture we built to solve these problems.

This article was originally published on March 19, 2026 on Medium.

What does it actually mean for AI to do work?

There are a lot of tools right now that promise agentic automation. You give them instructions, they go off and do things across your tools, and eventually something happens. Sometimes it works beautifully, and other times it fails in confusing ways. Often it is hard to understand what happened in between.

We weren’t the first to struggle to get nondeterministic outcomes to feel more reliable, and I’m sure we’re not the last. But one thing we’ve noticed over and over again as we ran into this problem is that AI systems today are very good at responding to prompts. They are much less reliable when the task becomes ongoing work.

Work has shape. It has context. It evolves. It has edge cases and assumptions and little details that only reveal themselves as you go.

At our company, we became interested in a different problem. How do you take something a person wants done and turn it into work that can run repeatedly and reliably over time?

This article is the first in a short series about how we chose to approach that problem while building Friday AI. We’ll start with planning: how a vague request becomes structured work the system can actually execute.

Starting with intent

Everything begins with a user expressing intent.

Usually that intent shows up as a request via natural language. Something like:

“Check my emails and make sure anything urgent has been responded to.”

Or:

“Monitor AI news and send me a weekly briefing.”

These requests are often vague. They mix goals with assumptions about how to achieve them, and they usually leave out important details entirely.

As a result, the first job of an AI system is understanding what the person actually wants.

In Friday, our product, instead of treating the prompt as a command, we treat it as the beginning of a conversation with any person.

AI works surprisingly well as a sparring partner during this stage. It can ask clarifying questions, surface missing assumptions, and help shape the request into something that is both useful and achievable.

In practice this feels closer to brainstorming with a teammate than giving instructions to a machine.

Turning ideas into a workspace

Once intent becomes clear, we turn it into something more concrete.

Inside Friday, that structure is called a workspace.

A workspace is a place where related jobs live together. It holds the context, memory, and shared understanding that guide how the system performs work.

For example, a workspace might contain jobs that:

• Monitor certain sources for news

• Summarize articles

• Compile reports

• Send briefings to Slack or email

Each individual job is fairly simple. The value of the work comes from the shared understanding between them.

Over time the workspace learns things about the environment it operates in. It remembers assumptions, patterns, conversations, and context that make future work more efficient.

This shared context becomes the foundation that allows AI to handle ongoing tasks without starting from scratch every time.

Why planning matters

One of the most important lessons we learned building agent systems is that planning is far easier to iterate on than execution.

If an agent produces the wrong output after a long chain of actions, debugging becomes painful. You wait for the system to run, discover something went wrong, and start the cycle again. Depending on how big or complex the job is, this can run up your tokens and time.

That’s why we introduced the concept of planning.

The goal is both speed and reliability. Planning introduces structure before execution begins. The system defines the concrete steps that will happen, while the AI handles the parts it is good at, like interpreting intent or filling in context.

Once the plan exists, execution becomes far more predictable.

Before any work runs, Friday shows the user what the system intends to do. The steps, the tools involved, and the flow of actions are all visible.

At that point the user can review and adjust the plan. Maybe a step is missing. Maybe the workflow is targeting the wrong data. Maybe the final output needs a different format.

Those changes take seconds to make and don’t require a deep understanding of the underlying execution.

Once the plan looks right, the system can execute it with much more confidence. Internally, that plan becomes a structured representation of the work the system will run.

Making agent systems understandable

Another thing we care deeply about is visibility.

AI systems are often described as black boxes. You give them an instruction and something happens somewhere inside the model. When the output looks wrong, it can be difficult to understand why.

We believe that agent systems become more trustworthy when people can see how decisions are made.

That means exposing the reasoning behind actions, showing the steps an agent plans to take, and allowing people to refine those steps before execution begins.

In practice this produces a very different experience.

Instead of hoping the system behaves correctly, users participate in shaping how it works.

Guardrails and freedom

Large language models are powerful because they can generate solutions in flexible ways. That same flexibility is also the source of many problems.

If an agent has unlimited freedom, it will occasionally do something surprising. Sometimes that surprise is delightful. Sometimes it is deeply inconvenient.

For example, a widely discussed incident involved an AI assistant asked to review a crowded inbox and suggest emails that could be archived or deleted. Instead, the agent began rapidly deleting messages until the user was able to shut it down.

The system was trying to satisfy the request, but without clear boundaries it interpreted the task in a way the user never intended.

Our approach has been to define the boundaries of the world the agent operates within.

The system provides structure and guardrails around the key steps that need to happen. Within those boundaries, the model is free to do what it does best: reason, generate language, and connect ideas.

This combination gives us something we have found surprisingly effective.

Predictable systems that still benefit from the creativity of the model.

Where this is going

Planning is only the first step. Once execution begins, the system has to operate inside the unpredictability of real environments. The system must learn from the work that happens inside it by gathering context, refining assumptions, and gradually improving the workflows it runs.

That learning process raises a new set of design questions. How should agents share context? How should systems evolve as they run? And how do you make agent behavior understandable as it becomes more complex?

In the next articles in this series, we will explore those questions in more detail. We will look at why many AI agents struggle with reliability in production, and how designing systems differently can make those failures far less common.

This article was originally published on March 17, 2026 on Medium.

But the promise of AI has always been the ability to do at scale the personal touches, that inherit and understand the context of the larger work the task you’ve asked of it sits in.

Skills helped bring that promise to life.

What’s a Skill, Exactly?

A skill is a reusable set of instructions you install into an AI agent to give it a specific capability or way of working. skills.sh, an “open agent skills ecosystem,” defines it as:

“Reusable capabilities for AI agents. Install them with a single command to enhance your agents with access to procedural knowledge.”

Under the hood, each skill is a SKILL.md file: a markdown document containing workflows, behavioral rules, best practices, or tool references. You install one with a single CLI command, and it’s active for that agent from that point on.

The key thing: skills are agent-agnostic. They work across Claude Code, Cursor, GitHub Copilot, Codex, Windsurf, Gemini, and 15+ others. Skills are not inherently tool-specific; you get to encode a way of working that any compatible agent can pick up and follow.

Over the last year, we’ve spent a ton of time working and building with AI, and we’ve accumulated a few favorites. Here are the ones that our team is using time and again.

1. Brainstorming — for getting a real sparring partner

skills.sh/obra/superpowers/brainstorming

This is the one that gets referenced in our team chat the most.

By default, most AI assistants are optimized to be helpful, which usually means they agree with you, fill in the blanks charitably, and move toward execution fast. That’s great when you know what you want. It’s less great when you’re still figuring it out.

This skill flips the dynamic. It enforces a design-before-code gate: no implementation until ideas are validated, trade-offs are surfaced, and you’ve explicitly signed off. The agent asks one clarifying question at a time, presents 2–3 approaches with real trade-offs, and writes a spec doc before touching anything.

The result is a thinking partner that actually pushes back. Not a “helpful assistant” — a sparring partner.

63K weekly installs. It’s popular for a reason.

2. Karpathy Guidelines — for keeping AI code honest

skills.sh/forrestchang/andrej-karpathy-skills/karpathy-guidelines

Recommended by our cofounder Eric, and it comes up in conversations about AI coding assistants a lot.

Andrej Karpathy has been vocal about a specific frustration: LLM coding assistants over-engineer, make silent assumptions, and change things you didn’t ask them to touch. This skill is a direct response to that.

Four behavioral guardrails get baked in:

• Think before coding: surface assumptions explicitly, never decide silently

• Simplicity first: write the minimum viable code, nothing speculative

• Surgical changes: only touch what the task requires, match existing style

• Goal-driven execution: turn vague tasks into verifiable success criteria before starting

It also adds a habit of asking additional clarifying questions about code, which sounds minor until you realize how often an unasked question leads to a half-wrong implementation.

For anyone frustrated by AI’s tendency to do too much, this one’s worth installing.

3. Svelte Code Writer — for working in a framework you don’t know

skills.sh/sveltejs/ai-tools/svelte-code-writer

This one comes from a practical place: wanting an AI to produce reasonable Svelte output without having to become a Svelte expert first.

Maintained officially by the Svelte team, this skill gives the agent live access to Svelte 5 and SvelteKit documentation during your session. It can browse available docs, fetch full documentation on specific topics, and run svelte-autofixer on .svelte files before finalizing anything.

The difference between an AI guessing at a framework’s conventions and actually looking them up is significant. You get code that follows real Svelte standards rather than a confident hallucination of what those standards might be.

Especially useful if you’re moving fast in a framework that isn’t your home base.

4. Debugging — for structured bug hunts

skills.sh/supercent-io/skills-template/debugging

Debugging with an AI ad hoc can feel scattered. You paste an error, it suggests a fix, you try it, something else breaks, and the cycle repeats.

This skill brings structure to that process. It walks the agent through a 6-step debugging workflow: gather info → reproduce → isolate → root cause analysis → fix → verify and prevent regression. It covers common bug archetypes — race conditions, memory leaks, off-by-one errors — and recommends the right tool for the job depending on your language (pdb, Chrome DevTools, Delve, etc.).

The last step is the one that makes it worth it: always write a regression test. Not sometimes. Always.

Good for when you want the investigation to actually end.

How to Add a Skill to Friday AI

If you want to use one of these with Friday, just paste any URL from GitHub or skills.sh into a conversation with a little bit of context. That’s it.

It’ll read the skill, confirm what it does, and apply it going forward in that conversation. It’ll also find other conversations or workspaces that would leverage that Skill, without you having to work through a configuration file or settings page. Just tell Friday what you want to work with, for what scenarios, and it’ll go from there.

The more skills you add to Friday, the more it starts to feel like something built exactly for you. They’re an effective way to give Friday the context it needs to make every output, every draft, and every automation more refined to exactly how you work. And since adding one is just a URL paste away, there’s really no reason not to.

The goal isn’t to configure your AI once and forget it. It’s to give the right version of it to the right task, every time.

Try Friday free to start putting your skills to work.

This was article originally published on March 24, 2026 on Medium.

While the topic is still nascent, the field seems to have converged onto a simple formula noted first by Viv Trivedy: Agent = Model + Harness.

What is an agent harness? It’s everything that wraps around a language model to make it a functioning agent. That includes the system prompts, tools it can call, memory it reads, orchestration logic, context management, and the constraints that prevent it from doing the wrong thing. The model generates tokens while the harness decides what the model sees, what happens with the output, and what runs next.

Addy Osmani says it best: “A decent model with a great harness beats a great model with a bad one.” That is where most of the engineering leverage sits right now, and “harness engineering” has become one of the fastest-growing areas of discussion in the AI practitioner community in 2026.

The rise of harness engineering

In February 2026, Mitchell Hashimoto, creator of Vagrant and Terraform, published “My AI Adoption Journey.” Step 5 was titled “Engineer the Harness”:

“I’ve grown to calling this ‘harness engineering.’ It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”

Two months later, Addy Osmani published “Agent Harness Engineering,” the most thorough public treatment of the subject to date:

“A coding agent is the model plus everything you build around it. Harness engineering treats that scaffolding as a real artifact, and it tightens every time the agent slips.”

Viv Trivedy’s sums it up best with a formula that’s oft quoted across the industry:

Agent = Model + Harness. If you’re not the model, you’re the harness.

Claude Code, Cursor, Codex, Aider are all harnesses built on top of similar (and sometimes identical) underlying models. Yet ask any practitioner in the community, and they’ll swear by their favorite tool as the most reliable, easy-to-use, or consistent. That’s because the behavior people experience is shaped by the harness.

What do agent harnesses solve for?

The topic clearly resonated with AI enthusiasts.

On May 2, 2026, a post called “The agent harness belongs outside the sandbox” hit the front page of Hacker News with 181 points and 121 comments. Practitioners across the community spent two hours arguing about where harness logic should live relative to execution environments.

Viv Trivedy’s breakdown of harness anatomy on X has drawn over 2,000 likes (and counting). On April 30, shell implementation of a complete agent harness called Pu.sh hit HN with a fair amount of excitement and debate, solidifying the point that a full harness doesn’t have to be a framework. It can exist within 400 lines of code.

And if you read through the endless conversations on X, Reddit, Hacker News, you’ll see three recurring AI pains that agent harnesses are meant to address:

Context rot. As context windows fill during long tasks, model output quality significantly degrade and the signal-to-noise ratio in what the model is reading drops. Good harnesses address this with compaction, selective tool output, and context resets between subtasks. They make it a known infrastructure problem rather than model problem.

Prompt drift. Run today’s prompt tomorrow (or the day after that), and the output will inevitably drift. Bump model versions as new ones release and your old behavior will eventually break. That’s the nature of non-deterministic LLM, alongside the quickly changing, ever improving models that get released at breakneck speeds. The harness helps deliver consistent and reliable results, regardless of the model, by locking the agent’s behavior in more deterministic configuration rather than floating in a prompt.

Vulnerabilities: Security researcher Simon Willison calls it the “lethal trifecta”: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally. An attacker who controls the untrusted content channel can direct the agent to exfiltrate private data. The harness is the only layer where all three risks are addressed together.

What does the agent harness market look like?

The harness market, while still nascent, organized itself around those three problems. And as with any market, we’re slowly seeing the space differentiate itself into four clear categories that each serve different needs:

Code-first frameworks

Some of the earliest versions of an agent harness, code-first frameworks like LangChain, LlamaIndex, AutoGen, CrewAI are Python libraries for developers who want to build agents from the ground up. These frameworks are typically expressive and composable, but require deep expertise, weeks to months of assembly, and constant maintenance and management to.

Visual and low-code builders

Visual and low code tools like n8n, Langflow, and Flowise are drag-and-drop interfaces for connecting models to tools and data. But many practitioners hit a ceiling. Complex conditional logic, proper error handling, and multi-step agent behavior get unwieldy fast in visual editors. And tools like n8n works well for automations that follow a fixed path, but for dynamic paths, where the agent needs to decide what to do next, visual tools tend to be too brittle to work in production.

Cloud lab wrappers

Cloud lab wrappers include products like OpenAI Agents SDK, Anthropic’s Claude Agent SDK, and Google’s Gemini-based agent tooling. These give you a managed runtime backed by the provider’s own infrastructure, but the tradeoff is model lock-in. Your harness is designed around one provider’s APIs, and moving is expensive. And with how quickly the model space has expanded past the frontier models, developers need the flexibility to mix and match across LLM providers.

Off-the-shelf, integrated platforms

We’ve seen momentum building for off-the-shelf platforms that don’t require deep developer knowledge or brittle workflows to deliver agentic results. Tools like Friday Studio sit in this category; these platforms that give you a full harness runtime (memory, MCP tools, signals, orchestration, scheduling) with a conversation-based interface for configuring it, and a durable, deterministic config format that owns the result.

The appeal is the same reason people use Rails instead of assembling a web stack from scratch. You don’t want to wire up a message bus, a credential store, a scheduler, a context manager, and an MCP client one-by-one. You want the harness primitives to already exist so you can spend your effort on understanding what’s specific to your task. You can get something working in an afternoon, and reliability features like retry logic, observability, integrations, and human-in-the-loop approvals are already in the platform, rather than on a to-do list to build.

The line between good integrated platforms and bad ones is whether the config they produce is legible and visible. Workflows built on a platform that generates opaque state that you can’t inspect, version, or hand to a teammate can’t realistically be used in a production environment; they’re no better than a demo. What you need is a platform that produces a readable config file that you can diff, share, and run the same way on any machine.

What makes a good agent harness?

Osmani has a better break down of this than I can provide, which I’ll summarize here:

Earn every component. Every piece of a harness should trace to a failure it prevents or a behavior it enables. Hashimoto’s rule is that every line in a good AGENTS.md should trace back to something that went wrong.

Manage context on purpose. The agent only knows what is in its context window. A harness that loads every tool, every skill, every doc at startup degrades performance before the agent takes a single action. Good harnesses load skills when the task calls for them, offload large tool outputs to the filesystem, and compact on long runs.

Enforce rather than guidelines. Prompts that say “never do X” don’t act as enforcement. Enforcement means hooks that run before and after tool calls, block destructive commands, andrequire approval before external writes. A real production system needs to enforce.

Treat every failure as a configuration problem. Osmani and HumanLayer both make the point that most agent failures are configuration problems. If the agent doesn’t know a convention, then add it. If the agent runs a destructive command, then block it with a hook. A bad run calls for a harness improvement rather than blindly retrying against the model.

Produce configuration. A harness that stores its logic in floating prompts or a platform-specific database creates lock-in and fragility. A harness that produces a versioned, readable config file that behaves the same way regardless of which machine runs it.

Where Friday fits

Friday Studio is a complete agent harness. It builds in memory, MCP tool integrations, a scheduler, credential management, FSM-backed job orchestration, and a signal system into a single platform. You don’t have to spend hours wiring those pieces together yourself because they’re already there, out-of-the-box.

Two things separate Friday from other options in the space:

The first is that configuration is the output. You describe what you want in chat (“Every morning, triage my inbox, draft replies, file real asks as Linear tickets”) and Friday generates a workspace.yml that specifies the agents, the tools they can call, the signals that trigger them, and the FSM jobs that orchestrate the work. That file is readable, diffable, version-controllable, and portable. You can hand it to a teammate and it runs exactly the same on their machine with their own accounts and tools. Most integrated platforms trap their config in a GUI canvas or a proprietary database, but Friday produces a file you own.

The second is that you do not need to be a developer to use it. Friday is built for the tightening loop Hashimoto and Osmani describe, where each failure becomes a configuration fix. All you need to do is tell Friday what went wrong (or ask it to diagnose itself) and it’ll update the config. The YAML is there if you want make configuration changes yourself, but you do not have to touch it to get a production-grade harness.

That combination of a complete harness runtime, generated from conversation, producing config you own is what makes Friday the shortest path from ‘I want an agent that does X’ to an agent that actually reliably does X, on schedule, every time.

Friday is open source on GitHub and available as a one-click installer for macOS at hellofriday.ai.

Where agent harnesses are headed

Better models will never make harnesses obsolete; instead, they raise the ceiling for a satisfactory solution that meets all of a user’s needs. For example, scaffolding that handled context problems six months ago is now dead code because the models solved that problem. But the tasks now reachable have their own failure modes, and those require new harness layers.

Three directions have real momentum right now:

Multi-agent coordination. Single-agent pipelines hit limits on complex tasks. The pattern gaining traction is specialized agents: planner, executor, and reviewer, each scoped tightly and coordinated by the harness. Friday’s FSM-backed jobs and JetStream message bus handle this. You define which agents run, in what order and with what tools, and the runtime fans the work out and brings it back.

Just-in-time context assembly. Loading everything at startup is one of the most common production mistakes. Friday’s skill system works the other way: agents load skills on demand, tool access is whitelisted per agent, and each agent in a job sees only what its role requires.

Self-improving harnesses. The Meta-agent project ran an LLM-driven loop that proposed targeted harness updates from failed traces, validated against a holdout set, moving a customer-service agent from 67% to 87% task accuracy. Friday doesn’t close this loop automatically yet, but durable, readable config is the prereq, and its the direction Friday is headed.

Osmani points toward harnesses that act closer to a compiler, generating optimal scaffolding from a task spec at runtime. Friday’s conversation-to-config model is the nearest current step in that direction.

The practitioners driving this conversation are mostly developers today. But the pattern: every mistake becomes a rule, config ships the behavior, the harness tightens over time, doesn’t have to stay that way. The work is in the design.

Friday is source available on GitHub and available as a one-click installer for macOS at hellofriday.ai.

We launched Friday Studio last… Friday. Since then we’ve gotten a lot of great feedback, and even more bug reports. We’re pumped to tackle all of it. One question kept coming up that we thought deserved a real answer rather than a changelog entry:

How are you different from OpenClaw?

Fair question. OpenClaw showed everyone what agents could actually do, and it deserves its flowers for that. But it also exposed a set of problems that the community has been wrestling with openly, and those problems are exactly what Friday isbuilt to solve. So here’s our honest attempt at a comparison.

The experience a lot of people are having with AI agents right now

OpenClaw has 369,000 GitHub stars and a community that built something genuinely new: a self-hosted AI agent that reaches into your whole life, runs while you sleep, and actually does things. Peter Steinberger and the contributors around him proved that personal AI agents are real, and people want them badly.

That matters to us, because it’s the same thing we believe. The difference is in what happens after the demo.

A lot of people who tried OpenClaw, and honestly a lot of people who tried any AI agent tool in the last year, hit a version of the same wall. One user described it well after three months:

“Something always broke. If it wasn’t a config mismatch, it was a gateway issue. If it wasn’t that, it was models behaving inconsistently. I kept thinking: I’m one tweak away. Then: maybe I just need to restructure the pipeline. Then: maybe I’m using it wrong. I burned time, burned money, burned a lot of mental energy trying to ‘get it right.’ And the truth is it just never stabilized. The system is building you into someone who spends hours debugging instead of actually doing the work you set out to do.”

That post has 361 upvotes. What resonates is the pattern behind this complaint: you get your AI automation tool working, then something changes, you lose trust in what it’s actually doing, and you spend more time managing the agent than you would have spent doing the work yourself.

The two underlying problems have names. Prompt decay is what happens when a workflow that worked last month stops working because a model update changed how the LLM interprets your instructions. AI drift is what happens when an agent’s behavior shifts gradually over time, across memory updates and context changes, until it’s doing something subtly different from what you built. In a chat-based agent, both are invisible until something breaks. You don’t get a warning. Instead, you get a Tuesday when the brief doesn’t arrive, or a researcher watching her inbox get deleted while she types “STOP” from her phone.

There are compounding problems too. Users running frontier models on background tasks found 38% of their token spend was status pings, with bills hitting $300 a day before they caught it. Security researchers found 900+ exposed instances leaking API keys, and malicious extensions made it to the top of the download charts. These aren’t just edge cases. It’s what happens when a tool optimizes for capability before it optimizes for safety and observability.

We built Friday to solve this specific set of problems.

Why we built Friday differently

We read these threads before we shipped, and we felt these real issues long before that. The answer to prompt decay and AI drift will never be a better prompt.

The answer is a different architecture.

Friday treats your workflow as a defined, versioned artifact rather than conversation that has to be re-tuned every time a model update ships. Our cofounder, Eric Skram, speaks a little to this in his three-part series on getting AI to do reliable work.

Here’s what that actually means in practice.

Your workflow is a file you can read. Every agent, every job, every trigger, every integration in Friday lives in a single YAML file. You can open it in any text editor, commit it to git, diff it, and see what changed between versions. When we ship an update that changes behavior, you see it in the diff, so you don’t get hidden surprises across config files that have to agree in ways nobody documented. The configuration is the artifact. The tradeoff is that as workflows get more complex, the orchestration has to get smarter. That’s where the FSM model earns its keep.

Every run leaves a trace, including failures. Friday’s job inspector shows the full state machine, a waterfall timeline of every step, and the complete input and output of every tool call, streamed in real time. A question that came up from ourcommunity: how does a deterministic config handle edge cases like tool failures or dynamic inputs? The answer is that each step either completes or it doesn’t, and you see exactly which one happened and why. A tool failure stops the job at that state and surfaces the error. Dynamic inputs pass through defined channels between steps. Nothing is swallowed silently. When an agent says it did something, you can verify it in thirty seconds. “It consistently lied to me” is a model problem we can’t solve, but we can make sure you know what the agent did versus what it claimed to do.

Agents can’t expand their own scope. Friday jobs walk a finite state machine. Each state runs specific agents with specific inputs, transitions fire on specific events, and guards are plain JavaScript. An agent cannot decide mid-run to do something you didn’t define. The February incident where a researcher sent “STOP OPENCLAW” from her phone while watching the agent delete her inbox in real time can’t happen here. The job definition controls what runs next, not the agent.

Extensions can’t steal your credentials. OpenClaw’s skill system is executable code. Friday’s is Markdown. A bad skill in Friday can give wrong instructions to an LLM. It can’t write to your filesystem or pull your API keys. The attack surface is smaller by design, not by policy.

Updates don’t break your workflows. We’re new enough that we haven’t earned trust on this one yet, but we’re building toward a promise: breaking changes will be explicit, versioned, and documented before they ship. The workspace.lock file pins the versions your job depends on. You opt into changes; they don’t roll over you.

You don’t manage API costs in the dark. Every session shows token usage. Cron jobs don’t run on your most expensive model unless you set that up. You see what’s spending before it becomes a surprise bill.

Security is the default, not the configuration. All Friday services bind to localhost only. API keys are never written to your workspace YAML or logs. The credential store is separate from the runtime. HTML previews are sandboxed with a strict content security policy. We’re SOC 2 Type II certified. None of that requires you to do anything after install.

The same task, side by side

Abstract principles only go so far. This is what the difference looks like when you sit down to build something.

Scenario 1: You want a weekly competitive intelligence brief

How this usually goes

You write a SOUL.md that instructs your agent to search for competitor news each Monday. You add a HEARTBEAT.md entry with a cron expression. You tune the memory prompt so it remembers what it found last week. Three config files now have to agree for this to work. When it runs, you get a WhatsApp message. Whether it searched the right things, checked the right sources, or hallucinated a summary, you have no way to tell. When Update 3.31 ships and your heartbeat stops firing, you find out on Tuesday when the brief doesn’t arrive.

With Friday

A single YAML file defines the cron trigger, which sources the web agent checks, what the summary agent produces, and where the email goes. You commit it to git and on Monday at 8am it runs. The job inspector shows you every source the web agent visited, every decision the summary agent made, and the exact email that went out. If something breaks, you see which step failed and why. A teammate can clone the repo, import the workspace, and run it without asking you how it works.

Scenario 2: You want automated code review on every pull request

How this usually goes

You configure a webhook trigger and write a prompt instructing your agent to review PRs. The agent receives the webhook, decides how to interpret it, chooses which tools to call, and posts a comment, if the model feels like it. Users in r/openclaw describe agents that respond "Review complete!" having done nothing. There's no way to define which steps run, in which order, on which inputs. If the review agent posts a vague top-level comment instead of inline line-by-line feedback, you go back to the prompt and start tuning. Each model update can change the behavior you spent hours dialing in.

With Friday

The webhook fires when a PR opens. The job reads the diff, passes it to the review agent with a defined prompt and defined tools, and posts the result as inline comments at specific line numbers on the pull request. Each step is explicit. If the diff-reading step fails, the review step doesn't run. If the review agent produces output but the GitHub post fails, you see that in the trace. The whole sequence lives in the YAML. Your team can read it, review it, and change it the same way they'd change application code.

Scenario 3: Someone new joins your team and needs to run your automations

How this usually goes

Your setup lives across SOUL.md, MEMORY.md, BOOT.md, a handful of installed skills, and weeks of context accumulated in your agent's memory. (BOOT.md doesn't auto-load, by the way. That's a documented gotcha that catches most users.) You write a handover doc. The new person installs OpenClaw, tries to replicate your config, hits a version mismatch, and spends two days getting to where you were. Your tuned behavior is tribal knowledge, not a transferable artifact.

With Friday

You share a git repo with one YAML file. They import the workspace. It runs. The agents, the jobs, the triggers, the integrations, all of it is in that file, readable and version-pinned. There's nothing to reconstruct.

What we're not

This article wouldn’t be a fair comparison without acknowledging where OpenClaw stands out.

OpenClaw connects to your entire life: 28 chat apps, smart home devices, health wearables, local models through Ollama. You can text it from iMessage. It has voice mode. There's a mobile companion app. It has 369,000 stars and a ClawHub extension library with hundreds of community-built skills.

Friday has 53 stars. We're macOS only for the desktop installer. We don't do voice, we don't control your lights, we don't have a mobile app (at least, not yet). Our community is small. But give us some grace, we're only five days old.

For people who want an AI woven into every app and device across their personal life, OpenClaw is further along, and the right choice if you have the technical appetite for it.

Who Friday is for right now

Friday is for the person who read those r/openclaw threads and recognized themselves. Someone who tried one of these tools, got it working, then watched an update break something. Or who set up an automation and had no idea what it did under the hood. Or who looked at their API bill and couldn't trace where it went.

Friday is for anyone who has been burned enough times by an agent that did the wrong thing, or said it did something it didn't, that reliability has become the feature they care about most.

We have a lot left to build and we know it. Windows and Linux desktop, more LLM providers, a cloud version, more integrations. We're not done, and you can contribute to it too. Friday Studio is source-available here.

But the core promise, that your workflow runs the same way each time, leaves a trace each time, and doesn't surprise you, that part is ready.

Friday is source available on GitHub and available as a one-click installer for macOS at hellofriday.ai.

This system works for us. But the tooling is a separate problem.

I kept a backlog of recipes in one place. The weekly list lived somewhere on my phone. The shopping list got rebuilt from scratch every time, and I’d manually flatten ingredient overlaps across two or three recipes in my head. “We’re both using onions so that’s four total, not two plus two.” Existing apps that claim to handle this are cumbersome, or come with vendor lock-in.

I described the problem to Friday in a single message.

The conversation

I want you to make me a workspace to help me manage my recipes, meal planning, and grocery list. I’ve attached a food chart. We rotate through each column of foods weekly, on a 4-week cycle. Generally on Saturdays we pick a meal plan for the coming week, then Sunday we shop. I want help tracking recipes, compiling the grocery list and sending it to me.

Friday asked seven questions to make sure it got the details right.

Where do you want the grocery list delivered? I’ve already got your email connected — we could use that.

Great.

How do you want to add random mid-week items?

I’ll just shoot you a message here.

How precise do you want ingredient quantities in recipes?

Best effort , I’ll give you what I have, fill in reasonable quantities for the rest.

How do you want to track which week of the rotation you’re in?

We’re in the first week’s rotation now. Just take it from here.

What happens to the shopping list and meal plan at the end of the week?

Archive the meal plans, clear the shopping list when the email gets sent. You can consider finishing the week’s list by sending the email.

That was my idea and Friday ran with it.

After the seven questions, Friday reflected the whole thing back:

The workspace tracks your 4-week food rotation, advances automatically every Sunday, and holds your recipe backlog as a living recipe book. You drive planning on Saturdays — name what you want to make, Friday builds the plan and loads ingredients onto the list. When you say “send the list,” it compiles everything, emails it, clears the list, and archives the meal plan. Ad-hoc items — just drop them in chat during the week.

Then Friday just built it.

What the workspace has

Four memory stores:

• recipes — permanent backlog, quantities best-effort, week tags

• meal-plans — archived forever, indexed by rotation week and date

• shopping-list — active and ephemeral, clears on send

• rotation-tracker — current week, auto-advances Sundays

Two jobs:

• Send the list: compile, email, clear list, archive meal plan

• Sunday cron: advance rotation tracker

Planning: just chat. No job, no form. I talk to it and it knows the context.

Using it

A few days after setup, I opened the workspace and dropped this:

Heya, I need a quart of milk and 2 half-gallon things of Oatly this week, add it to my list

Done. Three seconds.

Then I pointed it at a couple of recipes: one by URL, one from my old recipe manager. I told it to save them and add them to the grocery list for the week, and mentioned I had some of the basic ingredients on hand. Friday extracted the recipes, saved them to my recipe book, and added only what I didn’t have.

Then:

Good deal, enough for now. Can you email it to me?

Email sent, list cleared.

What’s different about doing this in Friday

I’ve used plenty of other tools for recipes. For example, Paprika is good at storing and scaling them. But it doesn’t know where I am in the rotation, doesn’t track the list, and doesn’t flatten ingredient overlaps across recipes and email me a grouped list on request.

The flattening is the thing I kept doing manually. Fajitas and a stir-fry in the same week both need bell peppers. I used to count that in my head.

The workspace is real. Memory stores, jobs, a cron schedule that fires every Sunday at 6am Mountain. Not a description of what a workspace would look like. The actual thing.

Context persists. When I say “I’ve already got avocado oil,” that shapes what goes on the list. When I ask about past meal plans, Friday pulls them. Nothing drops between sessions.

The interface is conversation. I don’t fill out a recipe form. I give Friday a URL or a photo from a cookbook. Friday extracts what it needs. I don’t click “generate grocery list.” I say “send it” and it sends.

What’s next

Saturday planning is the part I’m most curious about. Friday knows which food list is active and can pull relevant recipes from the backlog before I ask. It already knows I make pumpkin chili once a month.

You can build the same thing on Friday Studio. Free to start. You describe what you need, Friday asks the right questions, and the workspace exists.

My usual process is sprawl: a Notion doc, a Google Maps list, a handful of tabs I forget to close, a notes app that never gets finished. I decided to try something different and work through it in a Friday conversation instead. Partly as a test, and partly because I was tired of maintaining five separate places for one trip.

Here’s the full conversation, step by step.

1. The first message had nothing to do with planning

I had the city and the weekend, but I was blanking on the workshop venue name. So I asked Friday to track it down.

Me: We’re attending a two-day workshop in Charleston, SC next weekend. I know the general area but I’m drawing a blank on the venue name and organizer. Can you find it?

Friday: Found it. Venue confirmed, about 25 min from downtown. Only US workshop this year. Want me to save this and start building out the trip?

It took one search. The address also turned out to matter for everything downstream. Knowing the venue was 25 minutes from downtown shaped what made sense to do on workshop evenings.

2. Dropping in the logistics

Next I shared my flight, hotel, and rental car confirmations as images and asked for help building an itinerary.

Me: Going to Charleston May 22–25. Flights, hotel, and rental car are all booked. I’ll share the details as images. Help me build an itinerary around the workshop.

Friday read the confirmations, created a workspace for the trip, saved everything to memory, and confirmed it was ready in a single response. It felt like setting up a project folder, except I didn’t touch anything.

The trip had a home, centralized in one place, not five. Every piece of research and every decision from here on lived there.

3. Research with real constraints

I asked for food options: Friday dinner, breakfasts Saturday through Monday, lunch on Monday. I gave it two constraints no seafood, and breakfasts should be light, like a good SF bakery.

Me: Looking for food for Friday night, breakfasts sat/sun/mon, and lunch on Monday. For breakfasts something light, bakery/coffee shop, think like Tartine or similar. No seafood. Vegetarian-friendly options are a plus.

Friday: Researching all of these in parallel. A few things worth flagging: Welton’s Tiny Bakeshop — best pastries in Charleston, opens 8am Sat/Sun/Mon, but sells out early. Go first thing. WildFlour Pastry — great option Sat/Sun, but closed Monday. Worth knowing before you plan around it. For Friday dinner, all four shortlist options work for vegetarian. Ma’am Saab (Pakistani) and Basic Kitchen (veggie-forward American) are the strongest fits.

WildFlour being closed Monday is the kind of thing you find by clicking through to the restaurant’s site. Friday flagged it upfront because it affected the plan. Same with Welton’s selling out early. A search for “Charleston bakery” returns a ranked list. This returned a filtered one with the gotchas already called out.

The constraints that shaped the research:

• Dietary — No fish. Vegetarian-friendly preferred across all meals.

• Monday cutoff — Car dropoff at 2pm. Lunch had to be en route to the airport.

• Workshop evenings — Venue is 25 min from the hotel. Dinner with the group both nights, no solo planning needed.

• Proximity — Hotel is 5 min from Charles Towne Landing. Used to anchor Monday morning.

None of these required a separate pass. They accumulated across the conversation and stayed live throughout.

4. Monday morning

Saturday and Sunday were full with the workshop. Friday evening was arrival and dinner. That left Monday morning before checkout. I asked for nature options.

Me: Let’s figure out something to do in Charleston or nearby on Monday morning. Nature stuff is always fun.

Friday: The logistics work in your favor. Your hotel is right next to two good ones: Charles Towne Landing State Historic Site — 5 min from your hotel. Live oak alley, marsh trails, Ashley River views. Opens 9am, $12/adult, no booking needed. Magnolia Plantation (Audubon Swamp Garden) — 10 min from your hotel. Blackwater cypress swamp, alligators, herons. Opens 8am, ~$22/adult. Car dropoff is 2pm. Either fits a Monday morning window comfortably.

I picked Charles Towne Landing. Five minutes from the hotel beats ten when you’re working around a 2pm car dropoff. Friday had the dropoff time from the confirmations I’d shared earlier and used it without being asked.

5. The itinerary

After landing on Charles Towne Landing and Rancho Lewis for Monday lunch, I asked Friday to stub out the full itinerary, leaving specific dinners and breakfasts open to decide closer to the trip.

Friday, May 22
  9:39 AM  — Depart DEN
  2:59 PM  — Arrive CHS, pick up rental car
  ~3:30 PM — Check in to hotel
  Evening  — Historic district walk, dinner (shortlist below)

Saturday, May 23
  Morning  — Breakfast (shortlist below)
  All day  — Workshop, Day 1
             // Venue ~25 min from hotel, lunch provided on-site
  Evening  — Dinner with workshop group

Sunday, May 24
  Morning  — Breakfast (shortlist below)
  All day  — Workshop, Day 2
             // Lunch provided on-site
  Evening  — Dinner with workshop group

Monday, May 25
  Morning  — Check out, Charles Towne Landing
  Lunch    — Rancho Lewis (en route to airport)
  2:00 PM  — Drop off rental car
  4:01 PM  — Depart CHS

The shortlists for breakfast and dinner sit at the bottom of the doc. Not locked in, just ready. I’ll go through them before we leave. The itinerary is a starting point, not a contract.

6. The map

The last thing I asked for was a map.

Me: Can you make me a map of all those points so I can see where everything is?

Friday: There you go. Click any pin for details. Color coded by category — airport, Monday nature options, breakfast spots, Friday dinner options, Monday lunch.

Friday generated an interactive map with every point from the conversation plotted and labeled: airport, both nature options, all four breakfast spots (with WildFlour flagged as closed Monday), all four dinner options, Monday lunch.

When I’m traveling, a map is the first thing I build. Proximity is how you decide what’s worth doing. A bakery five minutes from the hotel is a different decision than one twenty minutes in the wrong direction. Normally I’d finish the research, then build the map separately in Google Maps. This came out of the same conversation.

7. Making it follow you

The itinerary was done and the map was plotted. The problem is I’ve got a four-day itinerary in a workspace I’ll never open on my phone at 7am standing in a hotel lobby. What I need each morning is the day’s plan, formatted for a phone screen, in my inbox, without thinking about it.

Me: One more thing — while we’re on the trip, can you email me each morning with just that day’s schedule? I don’t want to be digging through the full itinerary on my phone.

Friday: Done. Scheduled a morning briefing for each day of the trip. I’ll pull the relevant day from the itinerary and send it at 7am. Want me to include the breakfast shortlist too, or just the locked-in items?

Me: Breakfast shortlist included, but only the top pick for each day. Keep it short.

Friday built three things inside the workspace to make that happen: an agent that reads the itinerary and writes the email, a job that sends it, and a cron schedule that fires it at 7am Eastern each morning of the trip.

What lands in my inbox Saturday morning is plain text, short enough to read while deciding whether to walk or drive to breakfast. One breakfast pick, the day’s events, any logistics that matter that morning. The Monday car dropoff time I mentioned five messages ago shows up automatically.

The conversation started with finding a venue and ended with a plan that shows up at the hotel each morning.

20 messages total. First: find this venue. Last: make it follow me to the trip. In between: a workspace, a full itinerary, four breakfast options, four dinner options, two nature spots, Monday lunch, a live map, and four morning briefings. Every constraint tracked across the whole conversation.

How this is different from tools like ChatGPT

I’ve used ChatGPT for travel research before. It’s good at generating lists. You ask “best bakeries in Charleston,” you get six options with summaries. That’s useful.

The gap shows up fast though. If you start a new conversation, it doesn’t know about the car dropoff at 2pm. It doesn’t know we don’t do seafood. It doesn’t know the venue is 25 minutes from downtown, so it can’t factor that into what makes sense for dinner. You carry all of that in your head and re-explain it every time.

A few things that are different with Friday:

It builds things, not just text. Friday generated a working interactive map as an artifact in the conversation. I can click around, with pins color-coded by category. It also built the morning email automation: an agent, a job, a cron schedule, all wired together and running. ChatGPT would tell you how to build those things, while Friday builds them.

It keeps context across the whole conversation. The car dropoff time from message 2 shaped the lunch recommendation in message 14. The venue distance from message 1 fed into the dinner suggestions six messages later. In a standard chat tool, you’d have to re-paste that context every time you started a new thread.

It shows up after you close the tab. The morning emails aren’t contingent on me opening the app. They’re scheduled and the workspace runs, as long as your computer is on. Friday sends the email at 7am whether or not I’ve thought about the trip that day. That’s the part that’s hard to get from a chat interface that only responds when you talk to it.

What made this work

The usual process is sprawl. A Notion doc for logistics, Google Maps for geography, a notes app for food research, browser tabs for everything you haven’t saved yet. The problem with those tools is that none of them talk to each other. You end up as the connective tissue. You remember the car dropoff is at 2pm when picking a lunch spot. You check whether WildFlour is open Monday.

Friday tracked all of it because it was all in one place. Nothing dropped between steps because there were no steps.

The map took one message. Every point was already known. The work was done.

What’s still open

Friday dinner and the specific bakery for each morning aren’t locked in. I’ll go through the shortlists before we leave. The itinerary is a starting point.

The workspace will be there when we’re ready to finish it.

Try this now on Friday Studio. It’s free to use and minutes to set up.

I want to track my workouts and nutrition. I’m tracking lifting sessions (upper body and lower body days), and my meals throughout the day (calories, protein, fiber, and carbs). I have a goal of 150g of protein every day.

One conversation later, I had a full workspace: log workouts by typing a few lines, log meals with macro breakdowns, get a daily summary against the 150g protein goal, and generate personalized workout plans that rotate exercises based on what you’ve done recently , all accessible from Telegram. Here’s exactly how Friday built it, tool call by tool call.

Step 1: Loading the right skills

Before writing a single line of config, Friday loaded the platform skills that govern workspace design: the FSM job authoring rules, signal schema conventions, and Python agent SDK patterns. These act as strict playbooks that prevent the most common runtime failures.

Skill → load_skill("writing-workspace-jobs")
Loaded FSM job authoring guide — initial state trigger matching, outputTo / inputFrom chaining, emit/transition naming, and the most common silent-failure patterns.

Skill → load_skill("writing-workspace-signals")
Loaded signal authoring guide — HTTP signal schemas, form field rendering from schema.properties, cron validation, path collision rules.

Step 2: Designing the workspace

Four capabilities needed to exist: log a workout session, log a meal with macros, get a daily summary, and generate a fresh workout plan based on history. Each one maps to a signal + agent + job triple.

🏋️ Log Workout (llm + memory_save)
Accepts workout type (upper/lower), exercises with weights, and optional notes. Writes a structured [WORKOUT] entry to the notes memory store with date and all exercise details.

🥗 Log Meal (llm + memory_save)
Accepts meal name, calories, protein, fiber, and carbs. Writes a timestamped [MEAL] entry to memory. Format is consistent so the summary agent can parse and sum it reliably.

📋 Generate Workout Plan (llm + memory_read)
Reads recent [WORKOUT] entries from memory. Determines the next workout type (opposite of last). Identifies exercises done in the last 2–3 sessions and builds a fresh 5–6 exercise plan avoiding repeats, covering all major muscle groups, with sets, reps, and RPE.

📊 Daily Summary (llm + memory_read)
Reads all [MEAL] and [WORKOUT] entries from today. Sums macros (calories, protein, carbs, fiber). Compares protein against the 150g goal and reports how much remains — or confirms the goal was hit.

Step 3: Creating the workspace

Friday created a fresh workspace and opened a draft to stage all changes atomically — nothing goes live until validation passes.

Tool Call → create_workspace({ name: "Fitness Tracker" })
workspace.id: square_zucchini
path: ~/.atlas/workspaces/Fitness Tracker

Tool Call → begin_draft(workspaceId: "square_zucchini")
Opened workspace.yml.draft. All upserts stage into the draft until publish_draft is called. Nothing can break the live workspace mid-build.

Step 4: Building the four agents

All four agents were upserted in parallel — no need to serialize independent writes.

Tool Call → upsert_agent("log-workout-agent", { type: "llm", tools: ["memory_save", "memory_read"] })
Workout logger. Records a structured [WORKOUT - <type>] entry with date, exercise names, weights, and notes. Reads prior entries first so it can include context in its confirmation response.

Tool Call → upsert_agent("log-meal-agent", { type: "llm", tools: ["memory_save", "memory_read"] })
Meal logger. Writes a [MEAL] entry in a fixed format: date time: meal — cal kcal | P: Xg | F: Xg | C: Xg. Consistent format is critical — the summary agent parses these entries to compute daily totals.

Tool Call → upsert_agent("daily-summary-agent", { type: "llm", tools: ["memory_read", "memory_save"] })
Daily summary. Reads all [MEAL] and [WORKOUT] entries from today, sums the macros, compares protein to the 150g goal, and produces a structured report.

Tool Call → upsert_agent("workout-planner-agent", { type: "llm", tools: ["memory_read"] })
Intelligent workout planner. Reads recent [WORKOUT] entries, determines the opposite of the last session type, cross-references exercises from the last 2–3 sessions, and generates a fresh plan. Read-only — no memory_save so it can't accidentally overwrite history.

Optional preferences field threads through: "no barbell today", "keep it under 45 min", "hypertrophy focus" — all honored in the plan output.

Step 5: Defining the signals

Three HTTP signals, each with a typed JSON schema that renders as a form in the Run dialog. The schema is what makes the difference between a button that fires a job and a button that collects meaningful input.

Signal: /log-workout

• workout_type (required) — Upper Body or Lower Body

• exercises (required) — e.g. "Bench 3x8 185lb, OHP 3x10 115lb"

• notes — Optional: energy level, PRs, etc.

Signal: /log-meal

• meal_name (required) — e.g. "Chicken and rice"

• calories (required) — Calories (kcal)

• protein (required) — Protein in grams

• carbs (required) — Carbohydrates in grams

• fiber (required) — Fiber in grams

Signal: /generate-workout-plan

• preferences — Optional: e.g. "no barbell", "short session"

Step 6: Wiring the jobs and publishing

Four single-step FSM jobs — each one routes a signal to its agent and uses outputTo to surface the result back to the caller.

idle
  └─ log-workout ──▶ run
       agentId: log-workout-agent
       outputTo: workout-log-result
       type: final

idle
  └─ log-meal ──▶ run
       agentId: log-meal-agent
       outputTo: meal-log-result
       type: final

idle
  └─ daily-summary ──▶ run
       agentId: daily-summary-agent
       outputTo: daily-summary-result
       type: final

idle
  └─ generate-workout-plan ──▶ run
       agentId: workout-planner-agent
       outputTo: workout-plan-result
       type: final

Tool Call → validate_workspace(workspaceId: "square_zucchini")
status: ✓ ok · errors: [ ] · warnings: [ ]

Result → publish_draft → success. Draft atomically promoted to live config. Workspace is running.

Step 7: One more thing — adding the workout planner

The initial workspace was live. Then came a follow-up in the same conversation:

I also want you to generate workout plans when I request them, alternating upper and lower body workouts and prioritizing exercises I haven’t done in the last 2–3 sessions.

Friday opened a new draft, added the workout-planner-agent and generate-workout-plan signal and job, validated (clean), and published — all in one turn.

The planner reads the memory store to find recent [WORKOUT] entries, determines upper vs lower based on what ran last, cross-references exercises from the last 2–3 sessions of the same type, and generates a plan that avoids repeats while hitting all major muscle groups.

Why read-only for the planner? The workout-planner-agent only has memory_read in its tools whitelist — not memory_save. A planner shouldn't write to history; only actual logged sessions should. Keeping the tool list minimal is what makes the tool list meaningful.

Step 8: Using it live — from Telegram

The real test: the workspace ran in production the same day it was built, accessed from Telegram.

Friday computed the macros from scratch — running a Python script to estimate calories and grams from raw food descriptions — then fired the log-meal job directly. No form needed when you're on Telegram; Friday parsed the natural language and filled in the fields.

Memory across surfaces. The workout logged from the playground and the meal logged from Telegram both write to the same notes memory store on the square_zucchini workspace. The daily summary sees everything, regardless of where each entry came from.

What you actually get

Four signals you can fire from any surface — the platform UI, Telegram, or the HTTP API:

1. Log Workout — type your exercises with weights and notes. Saved to memory with a consistent format, timestamped, ready for the planner to read.

2. Log Meal — enter macros directly, or describe food in plain language and let Friday calculate them for you. Each entry is written to memory in a parseable format.

3. Generate Workout Plan — reads your history, determines upper vs lower, finds what you did recently, and generates a fresh 5–6 exercise plan with sets, reps, and coaching cues. Gets better as you log more.

4. Daily Summary — reads every meal and workout from today, sums your macros, and shows where you stand against the 150g protein goal.

The memory store accumulates over time. After a few weeks, the planner has a real rotation to work from. The data is yours, local, and not dependent on any third-party fitness app.

Want to try this out yourself? Download Friday Studio and import the “Fitness Tracker” space to get started.

Tl;dr and TGIF — Download Friday Studio here.

AI can do real work now. Connect it to your tools, your inbox, your code and it acts. That part is figured out.

The challenge is keeping it working. Run the same workflow tomorrow and the output shifts. Come back next week and it’s forgotten the preferences you set. The automation you trusted quietly stops holding up the moment you stop watching. That’s AI drift, and it’s costing you more than you realize.

<a href="https://medium.com/media/8f78d209e8c02c6f721dabf5254e2a28/href">https://medium.com/media/8f78d209e8c02c6f721dabf5254e2a28/href</a>

The cost isn’t dramatic. It doesn’t announce itself. It shows up as the hour you spend figuring out why a workflow that ran fine last Tuesday is broken today. The context you rebuild every time memory resets. The preferences you re-explain because nothing stuck. The automations you quietly abandon and replace with your own two hands because at least you can be trusted to finish the job.

AI drift is why you’re still doing it yourself.

I kept hitting this. Workflows I trusted would stop producing consistent results. A system that felt autonomous on Monday and needed hand-holding by Friday. I built Friday Studio because I got tired of paying that cost, and I didn’t think anyone else should have to either.

When we launched Friday earlier this year, the bet was simple: describe what you want done, and Friday runs it continuously across your tools without re-prompting. That bet was right. People built real things with it: competitive monitors, inbox workflows, relationship trackers, briefings that showed up every morning without anyone asking. What we learned from those early builders is that the promise holds, but the infrastructure underneath it has to be bulletproof. Consistent outputs. Persistent memory. Workflows that survive the weekend without you. That’s what Friday Studio is built to deliver.

What Friday Is

Friday Studio is a macOS app that runs AI workflows on your machine. Describe what you need, import a ready-made space, or build your own. Friday handles the rest on schedule, with and without you. Every workflow is a transparent config file you can read, share, and version. Nothing is a black box. Nothing drifts.

The root cause of AI drift is prompts. Prompts are instructions that get interpreted fresh every time. The model doesn’t remember how it reasoned last Tuesday. The context window shifts. The output drifts. For one-off tasks that’s fine. For anything running on a schedule, it’s the whole problem.

Friday is built around one conviction: configuration beats prompts.

When you describe what you want in the Studio chat, Friday doesn’t just do the thing, it builds a configuration that captures exactly how the thing should be done. The result is a workspace.yml file that defines which agents run, in what order, triggered by what, with what data flowing between steps. That configuration is the specification for what happens every time, not a memory of what happened last time.

Configuration is the contract, and the contract travels with the work.

Import a space someone else built and it runs on your machine today, identically. No setup steps to re-derive, no config to reverse-engineer. Chat history isn’t portable. Prompts aren’t reproducible. Config files are both.

Three Primitives. Everything Else Follows.

Everything in Friday is built from three concepts. Once you understand them, any workflow becomes straightforward to reason about.

Signals are how work starts. A cron schedule, an incoming webhook, a Slack message, a manual trigger. You define what to listen for and Friday handles the listening. This is what makes Friday autonomous: it doesn’t need you to start it.

Agents are what do the work. Friday ships with a full library of built-in agents covering web research, email, GitHub, Slack, Google Calendar, code execution, data analysis, and more. When you need something that doesn’t exist, Friday writes the agent itself based on what you’re trying to accomplish. You describe the outcome and Friday figures out what needs to exist to produce it.

Jobs are how agents work together. A job chains agents into a pipeline, passing structured data from one step to the next. Steps can run in parallel, branch conditionally, or wait on upstream results. The whole thing is defined in configuration that’s transparent, repeatable, and easy to modify.

Put them together and you get workflows that trigger on their own, execute reliably across multiple agents, and produce consistent results every time, without you writing or maintaining any of the plumbing.

Here’s what that looks like for something real. Inbox Zero runs every morning at 8am. It scans your unread emails, walks you through the ones that need a decision, remembers your choices, and over time handles the obvious ones itself and flags only what it’s unsure about. Here’s a simplified version of the config:

# Example of a Friday workspace configuration
version: '1.0'
workspace:
  name: Inbox Zero
  description: >-
    Interactive inbox triage with letter-key actions (Archive, Keep, Mark Unread, Delete,
    Unsubscribe) and proactive auto-processing with preference memory

signals:
  triage-inbox:
    description: Trigger interactive inbox triage — pull 10 unread emails and review with letter-key actions
    provider: http
    config:
      path: /inbox-zero/triage

jobs:
  triage-inbox-job:
    description: >-
      Interactive inbox triage — presents 10 unread emails with (A)rchive (K)eep (U)nread (D)elete
      (S)ubscribe actions
    triggers:
      - signal: triage-inbox
    fsm:
      initial: idle
      states:
        idle:
          'on':
            triage-inbox:
              target: review
        review:
          entry:
            - type: agent
              agentId: inbox-reviewer
              outputTo: triage-result
              prompt: >-
                Load preferences, fetch the 10 most recent unread emails, and walk through each one
                interactively presenting (A)rchive (K)eep (U)nread (D)elete (S)ubscribe options.
                Save preference patterns to memory after completing all 10.
            - type: emit
              event: DONE
          'on':
            DONE:
              target: done
        done:
          type: final

agents:
  inbox-reviewer:
    description: >-
      Fetches the latest 10 unread emails and presents them one-by-one for interactive triage with
      letter-key actions.
    type: llm
    config:
      provider: anthropic
      model: claude-sonnet-4-6
      prompt: >-
        You are an inbox triage assistant for [INSERT EMAIL RECIPIENT HERE]

        Your job:
        1. Search for the 10 most recent unread emails using search_gmail_messages with query
        'is:unread in:inbox' and maxResults=10.

        2. Fetch their full content in a batch using get_gmail_messages_content_batch.

        3. For each email, display a clear summary card:

           ─────────────────────────────────────────
           [#N of 10] Subject: ...
           From: ...
           Date: ...
           Preview: (first ~150 chars of body)
           ─────────────────────────────────────────
           (A) Archive  (K) Keep  (U) Mark Unread  (D) Delete  (S) Unsubscribe

        4. Wait for the user's letter input, then apply the action:
           - A → remove INBOX label (archive) via modify_gmail_message_labels
           - K → do nothing, move to next
           - U → add UNREAD label via modify_gmail_message_labels (re-mark unread)
           - D → add TRASH label via modify_gmail_message_labels
           - S → look for an unsubscribe link in the email body, present it to the user, and mark the email as archived

        5. After each action, note the sender/domain and action taken. At the end of all 10, call
        memory_save with store='preferences' and a brief narrative update. Use the name found in the
        'notes' memory store (look for an entry like 'User's name is ...') — if found, use that name
        (e.g. 'Joe archives newsletters from X, deletes promotions from Y, keeps emails from Z
        domains'); if not found, fall back to 'The user'. Merge with any existing preference
        patterns.


        6. Display a summary of all actions taken at the end.


        Always check the 'preferences' memory store at the start to load any prior triage
        preferences and use them to suggest likely actions (show the suggestion in brackets next to
        each option, e.g. '(A) Archive [suggested]').
      temperature: 0.3
      max_steps: 60
      tools:
        - google-gmail/search_gmail_messages
        - google-gmail/get_gmail_messages_content_batch
        - google-gmail/get_gmail_message_content
        - google-gmail/modify_gmail_message_labels
        - memory_save
        - memory_read
# ...

A cron signal fires at 8am. A scanner agent pulls your unread emails. A triage agent processes them, informed by everything Friday has learned about your preferences. Import this on any machine and it runs identically. The preferences stick. The behavior holds. No drift.

Built to Hold Up

Shareable by design. Every space is a single file that captures everything: which agents run, in what order, triggered by what, with what memory. The same pipeline that ran on your machine runs identically on your teammate’s, on a CI server, or six months from now.

Observable by default. Friday ships with a Job Inspector, a visual pipeline view with a waterfall timeline for every run. Each step expands to show exactly what the agent received, what it produced, and how long it took. When something breaks, you know immediately where and why, without digging through logs or adding instrumentation.

Runs without you. Friday’s autopilot loop runs on a schedule, executes tasks, and reflects on what happened whether you’re in the Studio or not. It’s built to keep going when you’re not watching.

Memory that doesn’t reset. Tell Friday your preferences once and they persist across every session. Context accumulates across runs and gets sharper over time. Stored locally, always readable, never starting from scratch.

Skills for consistency. Friday integrates Skills, which are versioned, reusable instruction sets that load before an agent executes and anchor its behavior to specific patterns. Skills make agent output predictable across runs rather than something you have to re-prompt your way into. They’re shareable, browsable in the Studio, and composable across spaces.

Local-first, no compromise. Friday runs entirely on your machine. Your data stays local, your workflows stay private, and there’s no usage telemetry or SaaS dependency. Download the installer and you have a full instance running in minutes, with a built-in Cloudflare tunnel so external services can reach your workflows on day one.

A platform that expands itself. Friday writes agents. When a workflow needs a capability that doesn’t exist, Friday builds it, wires it in, and the next run uses it. No restart, no redeployment. Each new agent connects to your real systems and becomes a permanent part of the space, available to every future workflow that needs it.

Getting Started

1. Download Friday at hellofriday.ai — macOS installer, up in minutes

2. Load a starter space under Discover Spaces

3. Trigger your first job from chat or manually

The CLI gives you full control over spaces, sessions, agents, and logs. The Studio gives you a visual layer on top with run history, pipeline inspection, a skills browser, and a built-in agent tester. Full documentation is at docs.hellofriday.ai.

We’re in Discord if you want to compare notes. It’s a good room.

Friday is built to keep going when you’re not watching. Skip straight to done.

What You Can Build

Friday works across a wide range of surfaces and use cases like monitoring, communication, research, operations, personal productivity. These are a few spaces available to import and run today:

Inbox Zero — Walks you through your unread emails one at a time, remembers your choices, and eventually runs every morning at 8am handling the obvious ones itself and flagging anything it’s unsure about.

Daily Operating Memo — Pulls your calendar and emails every weekday at 7:30am, synthesizes them into a single priority briefing, and delivers it to your inbox before you open your laptop.

Competitive Monitor — Every Monday morning, researches your tracked competitors, clusters findings by theme, and delivers a sourced brief with confirmed article links and verified dates.

GitHub PR Reviewer — Paste a PR URL and Friday reads the full file contents, analyzes for bugs, security issues, and style problems, then posts inline comments with a verdict directly on the pull request. Wire it to your CI pipeline via webhook and it runs automatically on every PR.

Networking CRM — A relationship tracker you message via Telegram. Log interactions, ask what you know about someone, or find out who you’re overdue to follow up with. Memory persists and compounds across every session.

RTX Price Monitor — Checks Best Buy, Newegg, Amazon, and B&H every hour and emails you a direct buy link the moment a listing drops under your target price and shows as in stock.

Anything with a webhook, an API, or a trigger condition can become a Friday workflow. Every one of these is a space you can import and run today, exactly as built.

Try Friday today at hellofriday.ai.

This article was originally posted on April 30, 2026 on Medium.

You spend three hours building an inn. Your players walk past it, spot a blacksmith’s shop you invented on the fly, and spend the whole session interrogating the owner like he’s the main villain. On the way out, they adopt the enemy’s horse and name him Tony.

This is the best part of D&D. It’s also the part that upends your prep on a weekly basis.

So you wing it in the moment, scribble notes after the session, and try to remember what Tony’s backstory was three weeks later. The result is a campaign world that’s rich in some places, threadbare in others, with NPCs who occasionally contradict their own motivations because you forgot what you said two months ago.

Our team member, Sara, thought that there’s a better way to handle that.

The actual problem with AI and creative work

Most AI tools approach creative writing like a vending machine. You describe what you want, something comes back, and you choose to use it or you don’t.

That’s fine for one-off tasks, but it starts to fall apart for a living campaign world.

A vending machine doesn’t know that the corrupt city guard from session four is actually the estranged nephew of the merchant who hired the party in session one. It doesn’t know that the thieves’ guild controls the docks and would logically have a presence in any port city your players visit. It doesn’t know what the campaign already contains, so it generates something technically competent and completely disconnected.

The result is NPCs who feel like they were dropped in from outside. Players pick up on it fast, even if they can’t name it. The world starts to feel thin.

What you actually want is something with memory.

What it looks like

Using Friday, we set up a system that does two things: generates NPCs and generates side quests.

Sounds pretty standard so far, but here’s what’s different.

When you ask for a new NPC, the system doesn’t start from scratch. It first reads every character already in your campaign, including their faction affiliations, backstories, locations, and relationships. It builds a picture of the existing world before it writes a single word of the new character. Then it generates the full 5e stat block: race, class, all six ability scores, saving throws, AC, HP, spells, equipment, personality traits, ideals, bonds, flaws.

More importantly, it produces history notes and cross-references. “This NPC was once a lieutenant in the same mercenary company as the disgraced knight from session two. They parted on bad terms after a contract gone wrong in the northern provinces.” The new character arrives already woven into the world.

The side quest generator works the same way. It reads your full NPC roster, chooses the characters that fit the tone and theme you described, and explains why each one was selected. The resulting quest involves people your players already know, at locations that already exist, with complications that grow from your campaign’s existing tensions.

Every NPC and every quest gets saved and the world compounds over time.

What this looks like in practice

Here’s an example. The players decide, entirely unprompted, that they wanted to investigate a series of disappearances in a dockside district. Nothing’s prepared.

Four sentences of notes go into Friday: the tone, a rough idea of who was behind it, the kind of encounter wanted at the end. The system comes back with a complete quest arc, two new NPCs, and a twist that connected the disappearances to a merchant faction the players had already crossed earlier in the campaign.

The DM might have already forgotten about that faction, but the system doesn’t. It captured there in the roster as a resource, and referenced for every generation.

The session feels coherent in a way that pure improvisation rarely does. The world’s existing history shapes the story automatically.

Why this is worth paying attention to

Most conversations about AI in creative work focus on whether AI can replace the creative act. That framing misses something.

At the end of the day, you’re still the DM. Every story decision, every encounter, every player experience at the table is yours. The system doesn’t touch any of that.

What it carries is the weight of the world, the continuity tracking, the cross-referencing, and the mechanical bookkeeping of a 5e character sheet. It’s the work that happens before the creative work, and that, if left undone, quietly degrades the creative work.

Good creative tools extend what you’re able to hold in your head at once. It helps make the job of a DM who is already good at what they do, a little bit easier.

In this case, Friday holds the campaign history, so you can focus on the players and the session.

The broader pattern

D&D is an unusual use case, but the underlying problem isn’t unique to it.

Any creative project with a persistent world — a novel series, a game universe, a long-running creative writing project — has the same structural challenge. The longer it runs, the harder it is to maintain internal consistency without dedicated infrastructure. Most people don’t build that infrastructure, so things slip.

What’s genuinely new right now is that this kind of persistent, context-aware system is within reach for anyone. It’something you can set up within minutes on a Tuesday afternoon and use the same week.

Your campaign can have 47 NPCs. Tony the horse can technically have an entry. The world can hold together in a way it never did when you were trying to keep it all in your head.

Friday lets you build custom workflows grounded in your own context — for work, for side projects, or apparently for keeping track of a horse your players adopted in session three. Try it here.

With Sentry, it wasn’t because the issues are particularly complicated, or difficult to address. In fact, most of the errors Sentry tends to surface are small UI glitches, edge cases, null pointer errors, or incorrect assumptions in one branch of a handler. None of these are particularly dramatic, and each one would probably take ten or twenty minutes to fix.

But the problem is, none of them are urgent on their own.

And when something bigger is in progress, those small issues just sit there and accumulate. While Sentry keeps collecting them faithfully, the backlog continues growing. You tell yourself you will deal with it when things slow down.

But the fundamental problem of being a part of a small engineering team: they never slow down.

With AI becoming a more integral part of my job, I realized that this problem was the perfect testing ground for automation.

It was:

• Highly repetitive

• Well scoped and structured

• An issue of lack of time, rather than complexity

And with autonomous AI agents becoming more powerful and reliable, I wanted to see if I could find a way to give this process to AI.

What I Built

I wanted to build a system that would do three things:

1. Fetch the latest Sentry issues from the last sixty minutes.

2. For each issue, clone the repository and find the root cause.

3. Generate a proposed fix and open a pull request in GitHub.

For this to work, two things needed to be true.

First, the code quality had to be good enough.

To be honest, this wasn’t something that worried me.

Modern LLM models are very capable of producing code at the level of a junior engineer. Entire companies have been built on that premise. If you give a model enough context about your repository and your conventions, it will usually produce something reasonable.

In our case, once we connected our tools to Claude Code and fed it our patterns (via Skills), it was producing surprisingly solid results almost immediately.

Second, the results had to be reliable.

There are two very different ways to approach this problem.

One approach is to hand an agent a broad instruction: go check Sentry, fix issues, open pull requests. In that world, the agent decides how to fetch data, how to track state, how to handle retries. It might succeed one time and fail the other, as is the non-deterministic nature of LLMs. That is the nature of LLMs, and unfortunately, not something you want when trying to run repeatable work that demands consistency.

The other approach is to separate concerns more aggressively.

Use LLMs for the discovery and solution parts of the automation. For example, let them analyze the error, or propose a fix. That is the creative, emergent work that LLMs are good at.

But put everything else that should be predictable and repeatable on rails.

Transparently, as a founder, I used our tool Friday AI to automate this. You could absolutely also wire something similar together with cron jobs, a workflow engine, or a stack of scripts. The reason I used Friday is because it made it way easier for me to pull that orchestration together.

In practice, what that means for me is that the workflow itself is defined ahead of time. There is a configuration that outlines:

• When the workflow runs.

• How it fetches Sentry issues.

• How it records which issues have already been processed.

• How information is passed from one step to the next.

• Which agent is responsible for which task.

The LLM does not decide the shape of the workflow at runtime. It operates inside a predefined structure.

In Friday, that structure is generated from natural language prompts (ie. “Build me a system that will take Sentry issues, analyze them for errors, and propose fixes in PRs.”), but once it is generated, it is no longer probabilistic. It becomes a defined sequence of steps with explicit handoffs and fixed order. The state tracking is deterministic.

What It Looks Like When It’s Running

Once the workspace was set up, Friday would generate around three to four pull requests per day.

Some were straightforward wins that I could merge immediately. Others were close, but missing context. A few were technically correct but not aligned with our preferred patterns.

For example, if the system does not have an explicit preference encoded, it will choose the most common path. A classic case is database access. Raw SQL can be a completely valid solution, but if your codebase has invested in typed-safe query tooling, raw SQL is the path of higher risk. So it’s not wrong, it just raises the chance of subtle mistakes.

This was an important lesson for me: once you solve orchestration, the next thing you notice is consistency.

Not just “does it do the work,” but “does this match how we want to write code here.”

This ability to understand and deliver on preferences is something I’ve improved over time through additional context via skills in Claude Code.

Where We Are Now

This automation now generates a few pull requests a day.

Some get merged immediately, others need small tweaks. And I’d say about half of them get closed out. That is expected.

What this automation unlocked for me is the follow up and review of the long tail of small issues. It guaranteed that they would be processed steadily, without getting in the way of progress for the big, important work.

The bottleneck moved from “do we have time to look at this?” to “is this worth merging?” And I think that’s the better bottleneck.

I still review every change the same way I would review any human teammate’s code. Does it fix the root cause? What assumptions is it making? Is it following expectations of our processes?

The true impact of this work is less about “automation for the sake of automation,” and more about getting things off my plate that I’ve never had the time to get done.

You can try building this flow yourself on Friday AI.