Campus - One project space for humans and AI agents

by
Campus gives builders a shared space to build with teammates and AI agents. Keep your repo, terminal, project knowledge, conversations, and agent work together in one persistent workspace, instead of scattering context across Slack threads, docs, tickets, canvases, and one-off AI chats. Campus is organized around the thing you are building, so humans and agents can pick up where the work left off.

Add a comment

Replies

Best

Love how quickly I can prototype in FlutterFlow, but please add proper state management for complex flows, something like scoped providers or a Riverpod-style pattern built in. Right now managing app-wide state across screens feels hacky with just shared widgets and global variables.

 hey Erdem! This particular launch is for our new tool Campus, an infinite canvas for organizing your work (possibly including FlutterFlow!). But always appreciate feedback for FlutterFlow! We're always looking for ways to improve the tool.

I've played with visual app builders before, but the extensibility with custom code is a big plus. How does FlutterFlow handle complex state management or third-party library integration?

 hey Aymen! This particular launch is for our new tool Campus, an infinite canvas for organizing your work (including FlutterFlow!). Hope you can check it out.

For FlutterFlow, I'd recommend checking out our YouTube channel for tutorials on building complex apps!

 you can use FlutterFlow (and Designer) INSIDE of Campus, alongside your other agents and tools!

This looks really compelling. How do agents on the canvas get their context, do they read the full repo, docs and past conversations automatically, or can you scope what each agent is allowed to see and touch (repo vs terminal vs docs)? Curious how you keep multiple agents' work reviewable when they're building alongside the team.

 

on context: agents in Campus get context from what's on the canvas, not from automatic full-repo ingestion. the idea is that you decide what each agent can see by what you put in their workarea. if you tile a terminal, a git worktree, a doc, and a browser preview together, the agent working in that context has access to those things. it's spatial scoping rather than permission-based scoping. you control it by what you put in front of it!

the Campus CLI is what gives agents the ability to act: move tiles, type into terminals, interact with webviews. so an agent can only touch what it can reach via the CLI in its workarea. if you don't give it access to a terminal, it can't run commands in it.

 just to tack onto this, each work area is scoped to a folder, so if you create one for a repo, a new agent tile in it it will have full access to the repo! And in general, each agent can use the CLI to view what other agents on campus are doing and view any outputs or assets from them.

Congrats on the launch! Since terminals and agents live on this shared canvas, if I close my laptop mid-task, does the agent keep running in the background, or does everything just pause until I'm back?

 thanks Arash! Work happens locally on your machine, so as long as it's awake the work continues. In my experience, the work pauses when my laptop closes but resumes as soon as I open it back up! So if I'm stepping out I generally leave it locked but open and let my agents do their thing :)

Congrats on the launch! The humans-plus-agents handoff is the part I always find hardest, knowing when an agent should stop and pull a person in vs keep going. Curious how Campus draws that line. Looks slick.

 thanks Bryan! That's a really good point, our main focus is to improve the handoff process and make it as easy as possible for your agent to get context from you and vice-versa. But the line of where to do the handoff we don't take an opinion on (yet) and leave that to the builder since it's a personal choice how much you want to be involved.

The challenge of shared context between human devs and AI agents is underrated. Most tools treat AI as a sidecar; mixing them in the same project space changes how you think about state and handoffs. Figuring out where agent context ends and human context begins is one of those problems that bites you late. How do you handle concurrent writes from agents and humans on the same resource?

 couldn't agree more, Anand! For code, we recommend the tried and true version control (as a team we lean heavily into worktrees). For most non-code resources it's effectively live collaboration (via CRDT) and making sure that agents have the tools (via the CLI) to understand what's currently present in the canvas live.

This feels like a step beyond AI chat by giving agents a shared workspace instead of isolated conversations. I'm curious how well it handles long running projects with multiple contributors.

 yes the sharing of context across agents on the same projects is one of the most crucial pieces that was missing for us. We've had no issue with long running projects (relying on git in most cases) but eager to hear how it works for you!

Love to see more connections between human and AI. Wondering whether other messaging tools are also supported as I dont use slack that much. And why do you folks pick slack?

 largely because we are Slack native - this was initially built for our team to develop, so we wanted it to feel familiar. What types of messaging tools would you like to see?

the "one persistent workspace instead of scattering across Slack/docs/tickets" pitch makes sense for the human side, but I'm curious about the agent side specifically - if two different agents (or an agent and a human) are working on the same repo context at the same time, does Campus have any concept of locking or conflict resolution, or is it more like a shared read layer where the actual edits still happen elsewhere and could still collide?

 great question! When it comes to working on code, in our experience git is the best layer for version control and context resolution. But for non-code assets and context, it's live collaboration so agents see the realtime state of the canvas (via the CLI) and can update it accordingly, with Campus using CRDT for conflict resolution if it's coming from separate users.

The one-click deploy to app stores and web is the detail that jumps out — most tools get you to a pretty prototype and then leave you stranded at the "now actually ship it" cliff. Keeping it fully extensible with custom code is the right call too; the no-code tools that trap you the moment you need something custom always lose me. Curious where the generated code lands on the clean-vs-just-works spectrum, since that's usually where these tools live or die. Congrats on the launch! 🚀

hey Kelly! This particular launch is for our new tool Campus, an infinite canvas for organizing your work (including FlutterFlow!). Hope you can check it out, but regardless thank you for the kind words!