The AI sidebar nobody uses is the most honest product signal of the year
Most social media operators I know are already running a project board that nobody fully trusts. The content calendar lives in one tool, the asset library in another, the approval thread in Slack, and the actual publishing in a third. So when a solo founder shows up on Product Hunt admitting that the AI sidebar in every project tool he has ever used “just sat there,” and then asks whether he built the wrong thing, that is not a product-launch post. That is a confession about how creators actually work — and it is worth reading closely, because the answer he landed on says something useful about how AI fits into a content operation. is.team is a project tool, not a social media scheduler. But the design decisions inside it are the ones I would want every scheduling and repurposing tool I pay for to steal.
What is.team actually is, minus the launch-day gloss
The pitch from solo founder Alper Mutlu Toksoz is that Jira is too much and Trello is too little, so he built a project board that lives on an infinite canvas — closer to FigJam than to a rigid Kanban column — with task management baked in. On top of that canvas, AI agents can join the workspace as members, not as a chat panel bolted onto the side. The listed features include sprint planning, meeting transcription, task creation from voice conversations, and workflow automation, plus an MCP server that lets external agents like Claude or GPT read cards, create tasks, and log time inside the workspace. There are native integrations with GitHub, Slack, Google Calendar, Google Drive, and Figma.
The free plan is three members, two boards, no time limit. Everything else — paid tiers, seat pricing, storage caps — is not disclosed on the page.
That is the whole factual surface. The interesting part is buried in the comment thread, where the founder answers questions in a way that reads less like marketing and more like someone who has actually used his own tool while annoyed at it.
The real problem is not “AI in your tool.” It is AI with no context and no leash.
The founder’s opening question is the one I want every social media tool vendor to sit with: does anyone actually use the AI sidebar? His theory is that the panel sits there because you open it, ask something, then copy the answer back into a task — a workflow with more friction than just doing the task. I have run that exact loop. When I was scheduling a month of posts across five platforms, the AI assistant in my scheduler was useful for exactly one thing: rewriting a caption I had already written. Everything else — deciding which hook belongs on TikTok versus LinkedIn, mapping a long-form YouTube script into four Shorts, tagging assets so a teammate could find them six weeks later — happened outside the tool, because the tool had no idea what my board was for.
That is the gap is.team is trying to close, and the mechanism is specific enough to be worth stealing. In the thread, the founder explains that each column on a board has its own context field where you write what that column is actually for — rules like “only bugs I have reproduced myself go here” or “nothing moves in here without a linked PR.” The agent reads that field before it touches anything. His framing: it is the onboarding sentence you would say to a new hire, except you only have to say it once.
Why this matters more for content teams than for engineering teams
Engineering columns are relatively self-describing. “In Review” is fuzzy, but “Done” is not. Content columns are worse. On a typical creator board, “Ready to publish” can mean the caption is written, the thumbnail is exported, the client approved it, or all three — and no two people on the team agree. If you have ever had a post go out with the wrong aspect ratio because someone moved a card too early, you already understand why a per-column rule field is not a nice-to-have. It is the difference between an agent that helps and an agent that just makes noise, which is the founder’s own phrasing in the thread.
I would bet the same pattern maps directly onto a repurposing pipeline. A column called “Needs Cut” on a video board could carry the rule “source must be at least 8 minutes and have a transcript attached.” A column called “Scheduled” could carry “UTM parameters must be set before this moves.” That is not glamorous AI. It is the boring scaffolding that makes the glamorous AI stop hallucinating tasks into the wrong lane.
The permission model is the part I would copy first
The detail that got the most traction in the thread — and deservedly — is that an AI agent inherits the permissions of whoever connected it. A read-only user gets a read-only agent. Access is granted board by board, and a board stays closed to agents until a human opens it. Inside a board, every column has its own switches: can the agent read it, move tasks in and out, leave comments. When someone leaves the team, their agent loses access with them.
One commenter, Priya K, called this a smart security move. The founder’s reply is the most trustworthy sentence on the page: it came from being paranoid rather than clever, because he did not want an agent quietly holding more access than the person running it.
For anyone running a social account with contractor access, this is the model to demand. Right now, most schedulers treat connected accounts as an all-or-nothing grant. If you hand a freelance editor access to your scheduler so they can draft captions, they can usually also publish, delete, and see every analytics dashboard you own. The idea that a tool would scope an agent — or a contractor — to one board, one column, read-only, and revoke automatically when the human is removed is a meaningful step past what I see in the mainstream scheduling stack.
Where the math breaks
Here is my honest read on the limit. Board-level and column-level permissions are clean when your work is organized as boards. Most creator operations are not. My content lives across a Notion database, a Drive folder, a CapCut project file, and a scheduler queue, and the “board” is a fiction I maintain for my own sanity. A permission model that only governs what happens inside one canvas does not protect the asset library, the raw footage, or the client folder. It is a real improvement over nothing. It is not a security boundary for a distributed content operation, and the founder does not claim it is.
The agent-moves-cards detail is a preview of where content tooling is going
Asked whether the AI can move cards, the founder gives a two-part answer. It can move tasks between columns, which is what people usually mean. It can also move the cards themselves around the canvas, set their position, draw connections between them, or rearrange a whole board in a single call — and it happens live, with cards sliding into place while you watch, no refresh.
That sounds like a party trick until you think about what it implies for a content calendar. If the canvas is just data, and an agent can rearrange it, then the visual layout of your board becomes a query result rather than a manual arrangement. A Monday morning view could show only the posts shipping this week, grouped by platform, with the ones blocked on client approval pulled to the top. You would not drag anything. You would ask, and the board would reconfigure.
I have not seen a mainstream scheduler do this. Buffer, Later, Hootsuite, and Metricool all give you a calendar view you arrange yourself. Notion gives you views you configure once and then maintain. The idea of a board that restructures itself per question is genuinely different, and it is the feature I would most want ported into a publishing tool.
Why TikTok creators should care more than LinkedIn ones
Volume changes the calculus. If you post twice a week on LinkedIn, a messy board is survivable. If you are running a TikTok account with daily posts, a YouTube channel with weekly long-form, and a repurposing pipeline feeding Shorts, Reels, and Pinterest pins from the same source footage, your board has hundreds of items and the manual arrangement tax compounds daily. The founder is candid about this in the thread: if you dump 400 tasks on the canvas and never filter, it will look like a mess, same as any whiteboard. The difference, he says, is that here you can hide things — filters strip the view down to one person, one label, one priority, or one sprint, and loose notes collapse into stacks.
That is a real answer, but note what it concedes. The canvas does not scale by staying tidy. It scales by letting you throw most of it away at any given moment. For a high-volume creator, that is probably fine. For a team that needs a shared, stable picture of what is shipping, it is a workflow change, not a feature.
What creators and social media teams can borrow right now
You do not need to switch tools to take three things from this launch.
Write the rule, not the column name. Whatever scheduler or board you use, put a sentence somewhere near each stage that says what has to be true before something moves forward. If your tool has a description field on a status, use it. If it does not, put the rule in the status name itself — “Scheduled (UTM set)” beats “Scheduled.” This is the single highest-leverage change, and it costs nothing.
Scope your AI and your contractors to the smallest unit that works. Before you connect an agent or invite a freelancer into a publishing tool, ask what they can actually see and touch. If the answer is “everything,” that is a finding, not a feature.
Separate capture from commitment. The founder describes meeting transcription that produces a summary, decisions, and action items automatically — but the notes land as a note on the board, and turning action items into real tasks is one more step where you see the list, delete the junk, and assign the rest. His reasoning is sharp: meetings produce a lot of sentences that sound like action items and are not. Apply the same rule to your content ideation. Let the AI dump twenty hook ideas into a scratch note. Do not let it create twenty tasks.
Where I think this falls short, and who should not bother
The free plan is three members and two boards with no time limit, which is generous for a solo creator testing a workflow. Beyond that, pricing is not disclosed, so I cannot tell you whether this is a $10-a-month tool or a $30-per-seat one, and that matters enormously for a small team.
The bigger open questions are structural. The canvas is the whole thesis, and the founder admits it gets messy at scale. The permission model is young, and he says so himself — he invites people to poke at it and find holes rather than hear about problems the hard way. That is the right posture, but it also means you should not treat this as hardened infrastructure for a client-facing operation yet.
Who this is not for: anyone whose content workflow is already fully served by a scheduler plus a spreadsheet. If your process is five posts a week, one platform, and no collaborators, the canvas will be more surface area than you need, and the AI agent will have nothing meaningful to do. This is a tool for people drowning in moving parts — multiple platforms, multiple collaborators, a repurposing pipeline, and a genuine coordination problem.
What I’d watch and test next
This week, I would do three things. First, open whatever board or scheduler you actually use and write one rule per stage — what has to be true before a card moves forward. Just that. Second, audit who and what has access to your publishing tools, including any AI features you have enabled, and note which of them could publish or delete without your review. Third, if you want to test is.team specifically, use the free tier for one real project rather than a toy board — the whole value proposition depends on having enough moving parts to get messy, and a two-card board will tell you nothing. Watch for two things in your test: whether the column context fields actually change what the agent does, and whether the canvas stays usable once you pass a few dozen cards. If pricing shows up and the math works for a small team, this is worth a longer look. If it does not, the design ideas are still free to steal — and the permission model is the one I would steal first.
