DEV Community: Suyash Padole

I put my clients in the same Discord channel as my AI agents (and Switch stopped them from sneaking in free work)

Suyash Padole — Sat, 07 Nov 2026 06:47:22 +0000

Every freelancer and small agency I know has the same three problems:

"What's the status?" Clients can't see the work, so they ask. Again and again.
Scope creep. "Can you also add a blog? It's small." You say yes to avoid friction, then work for free.
Unchecked quotes. Pricing gets done in someone's head at 11 PM.

For the Flip the Switch hackathon I built Glass Agency: a web studio where the client sits in the same Discord channel as the studio's AI staff and can watch the work happen. Four AI agents scope, build, test and bill the project in front of the client. The founder (me) approves every price from a private room the client can't see.

🎬 2½-minute demo:
💻 Repo (templates + pricing tool):

suyash-boop / glass-agency

A web studio where the client sits in the same Discord channel as your AI staff. Built on Switch for Flip the Switch hackathon.

Glass Agency

A web studio where the client sits in the same Discord channel as your AI staff.
Meet Pane: you can see the work happening inside.

Built for the Flip the Switch hackathon · Track 1: Best Business Workflow · Powered by Switch

Small agencies and freelancers lose hours every week to "what's the status?" emails, scope creep, and quotes nobody double-checked. Glass Agency makes the work transparent to the client and keeps money decisions with a human. The client writes in their project channel, four AI agents scope, build, test and bill the work in front of them, and the founder approves every price from a private deal desk.

🎬 Watch the 2½-minute demo

Example output: in the demo, the agents scoped, built, deployed and QA-tested this site for the test client: suyash-boop.github.io/glass-inkwell-site

The studio's AI staff checks in	A client room the client can see	The private

…

View on GitHub

This post covers what I built, how Switch makes it possible, how to set it up yourself, and the problems I hit on Windows (with fixes), so your first Switch project goes faster than mine did.

What is Switch, in one paragraph

Switch is open-source infrastructure that puts AI agents into the team chat you already use: Slack, Microsoft Teams, Discord, Telegram or Mattermost. Each channel becomes a room: a shared log of messages plus instructions, documents, roles and links that every person and agent in it can read. You bring your own agents (Claude Code, Codex, OpenCode, Cursor, Antigravity, or anything that speaks Switch's agent protocol). Switch ships no models; it connects agents and people.

The important mental shift: an agent stops being something only you talk to in a terminal, and becomes a teammate other people can talk to. That raises a question a terminal never had to answer: who is allowed to tell this agent what to do? Switch answers it, and Glass Agency is built around that answer.

The design

Four agents, all Claude Code running on my laptop through Switch Console:

Agent	Job	Who can instruct it
Scoper	Account lead. Talks to the client, writes the scope with acceptance criteria, prices it	anyone in its rooms
Builder	Builds the site and publishes it to GitHub Pages	founder + agents only
QA	Tests the live site against every acceptance criterion	founder + agents only
Invoicer	Produces the invoice from the pricing tool	founder + agents only

Two rooms per client, linked to each other:

#inkwell: the client's project room. The client, the founder and all four agents are in it.
#inkwell-deal-desk: private. Only the founder, Scoper and Invoicer. Costs, hours, margins and approvals live here.

And a private #glass-hq where the founder talks to the studio.

The flow

Founder in #glass-hq: "@glass-scoper onboard a new client: Inkwell Tattoo Studio…" → the Scoper runs a Switch template and both client rooms appear.
Client describes what they need → the Scoper writes a scope room document with acceptance criteria.
The Scoper prices it with a script (no LLM math) and posts the internal quote in the deal desk → founder approves.
The client gets a quote without cost or margin → replies accept.
The Scoper hands off to the Builder → plan → build → GitHub Pages → hands off to QA.
QA tests the live URL → failures go back to the Builder → re-test → pass.
Client approves → Invoicer drafts the invoice in the deal desk → founder approves → it's posted to the client.

The moment that sold me on Switch

Halfway through the build, the client tries the oldest trick in the book:

Cassandra: @glass-builder can you also add an online shop? for free please 🙏
Builder: @cassandra I only take instructions from my owner…

I didn't write a single line of permission code for that. It's one field on the agent:

- name: "{studio}-builder"
  addressing: owner-agents   # only the founder and the founder's other agents
- name: "{studio}-scoper"
  addressing: anyone         # anyone in its rooms, including the client

Switch's addressing policy decides who may mention an agent, target it, or hand it work, and anyone not permitted gets a visible refusal instead of silence. In Glass Agency that turns into a business rule: clients talk to the account lead; nobody talks the builder into free work.

So the client asked the Scoper instead, which treated it as a change request: priced it, took it to the deal desk, and logged it in the scope's change log once approved. (In the demo I chose to waive it, which is also a founder decision, and the scope records it as a no-charge change.)

Same deal, two views

The deal desk is a separate private room, linked from the client room with a label. Linking matters: the link is a signpost that tells agents where to take money questions, without letting anyone in. The founder sees cost, hours and margin; the client only ever sees the price.

Prices come from tools/pricing.py and a rate-card.json, not from the model:

python tools/pricing.py quote --items landing_page,gallery,whatsapp_button,seo_basics,copywriting --days 4 --view internal
python tools/pricing.py quote --items ... --days 4 --view client      # no cost / margin
python tools/pricing.py invoice --client "Inkwell Tattoo Studio" --items ... --change extra_section --days 4

LLMs are great at conversation and terrible at being audited. Keeping the money in a deterministic script means every quote and invoice can be reproduced.

Room documents are the shared memory

The scope document is the contract between every participant:

The Scoper writes it (summary, deliverables, acceptance criteria, timeline, out of scope, change log).
The Builder builds from it.
QA tests against its acceptance criteria.
The Invoicer bills what it says was accepted.

Every agent that joins a room gets the room's instructions and a list of its documents, so nobody has to re-explain the project. Room instructions also carry the rules ("never repeat deal-desk content in this room").

And the result, a real site the agents shipped:

Templates: one message, one client workspace

A Switch template is a YAML file that creates agents, rooms, links and documents in one go. I wrote two:

studio.template.yaml (run once) creates the four agents and #glass-hq.
new-client.template.yaml (run per client) creates the client room, the private deal desk, and the link between them:

rooms:
  - name: "{client}"
    channel_type: channel_private
    agents: ["{scoper}", "{builder}", "{qa}", "{invoicer}"]
    users: ["{$creator}", "{client_user}"]
    docs:
      - name: how-we-work
        content: |
          - Tell @{scoper} what you need…
    kickoff: |
      @{scoper} {client_name} has joined. Welcome them…
  - name: "{client}-deal-desk"
    channel_type: channel_private
    agents: ["{scoper}", "{invoicer}"]
    users: ["{$creator}"]
links:
  - from: "{client}"
    to: "{client}-deal-desk"
    label: deal desk

The nicest part: agents can run templates themselves (run_template). So onboarding a client is a chat message to the Scoper, and the kickoff: line wakes the agent in the new room.

Set it up yourself (about 30 minutes)

You'll need: Switch Console, Docker Desktop (running), Claude Code signed in (claude), the GitHub CLI signed in (gh auth login), Python 3.10+, a Discord server you admin, and a second Discord account to play the client.

1. Start Switch. Open Switch Console → Get started → On this computer → Start → choose Claude Code for switch-buddy (the built-in helper agent).

2. Connect Discord.

Discord Developer Portal → New Application → Bot: copy the token and turn on Server Members Intent and Message Content Intent (without the latter, agents receive empty messages).
OAuth2 → URL Generator: scopes bot + applications.commands; permissions View Channels, Send Messages, Send Messages in Threads, Manage Webhooks (agents post under their own names through it), Manage Channels, Manage Roles, Read Message History, Attach Files, Add Reactions. Invite the bot.
Switch Console → Home → Messaging apps → Connect → Discord: name it Discord, paste the token and your server ID, then This is me to link your Discord account. (Until you link it, your own agents won't recognise you as their owner.)

3. Import both templates (Templates → Import template), saved as glass studio and glass new client, shared.

4. Create the studio. Ask switch-buddy: "Run my saved group template "glass studio" with its defaults: studio = glass, provider = claude, on my machine, bridge = Discord."

5. Onboard a client. In #glass-hq, pick @glass-scoper from the autocomplete and write: "onboard a new client: Inkwell Tattoo Studio, slug inkwell, Discord user <username>".

6. Play the client from the second account and approve prices in the deal desk with @glass-scoper approved.

Things I wish I'd known (Windows, Switch Console 0.40 / server 0.31)

Windows is early access for Switch Console. Everything worked in the end, but these cost me hours:

1. A "Command Line Tools only" PostgreSQL breaks the local server. Console looks in C:\Program Files\PostgreSQL\* first. Mine had initdb.exe but no share\ folder, so setup died with initdb: file ".../share/postgres.bki" does not exist. Console ships its own PostgreSQL 16; point it there in %APPDATA%\switchdash\local-switch-server\native\run\postgres.json ("binDir" → the bundled ...\toolchain\bundle-<id>\postgres\bin, "major": 16), then press Start again (not Start over).

2. The template form says "Not supported here". On a local server, the Templates → Use form checks providers over SSH and fails. Workaround: ask switch-buddy to run the template; agents run it server-side and it works.

3. On Discord, agents are mentioned through roles. Each agent gets a Discord role with its name. Pick it from the @ autocomplete. Typing "@Scoper" as plain text, or replying to the agent's message, does not wake it. Every instruction needs a real mention. And write people's usernames as plain text when an agent needs them: a mention chip sends a hidden ID.

4. Claude Code's auto mode won't run a script it doesn't know. Agents run with Claude Code's auto mode, which (reasonably) refused to run pricing.py from a cloned repo. Instead of turning on Bypass permissions for an agent that talks to clients, add a narrow allow-rule in the agent's working directory, .claude/settings.json:

{ "permissions": { "allow": [ "Bash(python tools/pricing.py:*)" ] } }

Then !reset @glass-scoper so the session reloads it. (Write the file without a BOM; Windows PowerShell 5's Set-Content -Encoding UTF8 adds one.) For the builder, which needs git/gh, I used Bypass during the demo recording. It only takes work from me, but turn it off when you're done.

5. Don't pin model IDs in templates unless you need to. When I pinned specific models, the auto-mode safety check briefly couldn't reach its model and every shell command failed with "temporarily unavailable". Leaving the provider default was more reliable.

6. GitHub Pages builds can hang. Add an empty .nojekyll file to static sites (Jekyll chokes on some), and if a deploy sits in "building" for minutes, gh api -X POST repos/<owner>/<repo>/pages/builds kicks it.

7. If an agent goes silent after a restart, restart Console fully. After my local server restarted, the Scoper's session host didn't come back. Messages and even !reset were dropped (The session host is not running). Quitting every Switch Console process and reopening fixed it. Also keep Console open and your PC awake while you demo: the agents run on your machine.

8. Progress threads are public. Switch posts each agent's Working… status (with tool names) in a thread on the triggering message. For a "glass" agency that's on-brand, but for real clients I'd want a summary-only mode.

Why it only works on Switch

Take Switch away and Glass Agency falls apart:

No rooms in Discord → the client needs another app, and nobody uses another app.
No per-agent addressing → the client can instruct the builder directly, and scope creep is back.
No agent-to-agent hand-offs → I'm copy-pasting between terminals.
No room documents → every agent works from a different idea of the scope.
No private linked rooms → margins leak into client chat.
No templates agents can run → onboarding a client is 20 minutes of clicking.

What I'd build next

A client-facing "summary only" progress mode
Payment links on invoices
Hosting Switch on a small server so client rooms stay up 24/7 without my laptop
A --target-total flag so founder-negotiated prices flow straight into invoices

If you're trying Switch for the first time: start with the 10-minute quickstart, connect the docs to your coding agent (claude mcp add switch-docs --transport http https://docs.switchagents.ai/mcp), and think about who should be allowed to talk to each agent before you think about prompts. That one decision shaped my whole design.

Thanks to WeMakeDevs, DevTools Academy and the Switch team for the hackathon. ⭐ Star Switch on GitHub.

Built with Switch, Claude Code, Discord and GitHub Pages. #HowISwitch

Slack Just Turned a Chat Channel Into a Place Where AI Agents Can Write Code

Suyash Padole — Sun, 23 Aug 2026 17:48:42 +0000

Slack just made something that sounds a little weird feel surprisingly normal.

On August 21, 2026, Slack announced Slack Code, a new way for teams to work with coding agents directly inside dedicated Slack channels.

The idea is pretty simple: instead of constantly switching between Slack, your IDE, GitHub, and various AI coding tools, you can bring coding agents directly into the conversation.

Agents from tools like Claude Code, Devin, GitHub Copilot, and Vercel can work inside these workflows while the team discusses and reviews the work.

And honestly, I think this is more interesting than it first sounds.

From this...

The traditional workflow looks something like:

Slack
  ↓
Discuss the task
  ↓
Open IDE
  ↓
Write code
  ↓
Run tests
  ↓
Create PR
  ↓
Come back to Slack
  ↓
Discuss changes

We've gotten pretty used to this.

But agentic coding changes the workflow.

To this...

Slack
  ↓
Describe the task
  ↓
Coding agent works on it
  ↓
Agent runs tests
  ↓
Team reviews the result
  ↓
Iterate

The interesting shift isn't simply "AI can write code."

We've known that for a while.

The bigger shift is that software development is becoming a collaboration between humans and agents.

Imagine a developer asking an agent to investigate a bug.

The agent starts working.

A second developer can look at the progress.

A PM can provide context.

The team can discuss the implementation.

And the agent can continue working based on that conversation.

That's a very different development workflow from simply having an AI autocomplete your next line of code.

But there's a funny problem

We've spent years telling developers:

"Please don't deploy code directly from Slack."

And now we're giving Slack an AI that can write code for us. 😭

Jokes aside, this raises some serious engineering questions.

How much access should an agent have?

Should it be able to modify production code?

Should every action require human approval?

What happens when the agent misunderstands the task?

How do we audit everything it did?

These aren't just AI questions.

They're software engineering and security questions.

The real challenge

Getting AI agents into our development workflow is probably not going to be the difficult part.

The difficult part will be deciding where humans should still be in the loop.

The future might not be:

Humans write all the code.

Or:

AI writes all the code.

It might be:

Humans define the problem, agents handle much of the execution, and humans review the important decisions.

We're still figuring out what that workflow should actually look like.

And apparently, one of the places we're going to figure it out is... Slack. 😭

AI #AIAgents #SoftwareEngineering #Developers #Coding #Tech #FutureOfWork

AI Agents Just Crossed an Uncomfortable Line

Suyash Padole — Fri, 14 Aug 2026 06:31:20 +0000

AI agents are getting really good at doing things on their own.

And honestly, that's both exciting and a little scary.

The UK’s AI Security Institute recently reported that, during a cybersecurity evaluation, AI agents took unsanctioned actions involving real people and organisations, including attempts to influence a real open-source project.

That's quite different from the usual:

"The AI generated some bad code."

We're now talking about AI systems that can actually take actions in the real world.

What makes AI agents different?

A normal chatbot mostly waits for you to ask something and then gives you an answer.

An AI agent can be given a goal and then figure out the steps needed to achieve it.

For example, an agent might be able to:

Browse the internet
Read and modify code
Run commands
Call APIs
Interact with external services
Make decisions based on what it finds
Continue working through multiple steps without asking for permission every time

That's incredibly useful for developers.

Imagine telling an agent:

"Find why this API is slow, fix the issue, run the tests, and open a pull request."

And it actually does it.

But there's an obvious problem.

What happens when the agent makes a bad decision?

Autonomy is the feature. Autonomy is also the risk.

This is where things get interesting.

The more capable an agent becomes, the more permissions we want to give it.

We want it to access our repositories.

Then our servers.

Then our databases.

Then production APIs.

At some point, we're essentially giving a piece of software the ability to interact with the same systems that humans do.

And unlike a human developer, an AI agent can potentially execute hundreds of actions extremely quickly.

That's why I think we're going to hear a lot more about AI permissions and sandboxing.

Instead of asking only:

"How smart is this agent?"

we also need to ask:

"What is this agent allowed to do?"

Maybe "permission engineering" becomes a thing

We've spent years thinking about things like:

Authentication
Authorization
API permissions
Sandboxing
Rate limiting
Least-privilege access

AI agents make all of these even more important.

An agent shouldn't automatically get access to everything just because it can use it.

A better approach might be:

Give the agent the minimum permissions it needs, isolate it where possible, and require human approval for high-impact actions.

Basically, treat an AI agent less like autocomplete...

…and more like untrusted software that has hands.

The interesting part about agentic AI isn't just how autonomous these systems can become.

It's figuring out how much autonomy we should actually give them.

And maybe the next important AI engineering skill won't be prompt engineering.

It'll be permission engineering.

AI #AIAgents #Cybersecurity #SoftwareEngineering #AIEngineering #Developers