A user gives an agent a task. Maybe it needs to read invoices, update a CRM record, check an internal dashboard, or call a few APIs on their behalf. The easy model is to let the agent act with whatever access the user already has.
But I am not sure that makes sense once the user has a lot of authority. If I can delete a workspace, change billing, export customer data, or invite an admin, does an agent helping me with one task need access to all of that too Giving the agent its own identity and narrower permissions sounds safer. But then another question comes up: how narrow can those permissions be before the agent keeps hitting boundaries halfway through the task?
So I am curious how teams building agents are thinking about this today.
Does the agent inherit the user s authority? Does it get its own identity with access only to specific APIs or actions? Or are you handling this another way? And where do you draw the line between the user is allowed to do this and the agent is allowed to do this for the user ?
Making a product is one big challenge. But shifting your mindset from building to marketing it might be an even bigger one. As makers, we spend so much time improving the product. Then comes the question: How do we get people to discover it - and ultimately turn that attention into real customers and sales? I'm not sure traditional approaches like email marketing and constantly posting on social media are enough anymore. The way people discover products is changing. So I'm curious:
How do you approach marketing your product? And for the marketers here: What would you consider a modern marketing approach in 2026-2027? What would you advise an early-stage founder to focus on? I'd love to hear different perspectives...
I ve been thinking about where the line actually is with Kubernetes. When you re a small team, something like Render, Railway, Fly, or a managed cloud setup can take you pretty far. You push code, it runs, and nobody has to become the accidental infrastructure person. Then the product grows. You have more services, workers, cron jobs, environments, traffic that doesn t behave nicely, maybe different scaling requirements. At some point someone says, We should probably move to Kubernetes before this becomes a mess. But moving early can create a completely different mess.
Now someone needs to understand the cluster, networking, autoscaling, deployments, observability, upgrades, Helm/YAML, and what happens when something breaks at 2 AM. On a five-person engineering team, that can very quickly become one person s unofficial full-time job. Waiting too long doesn t sound great either. If you eventually need Kubernetes, migrating when the existing infrastructure is already struggling is probably the worst possible time to do it.
So I m curious what the actual trigger has been for teams here.
Was it traffic? Number of services? Cloud cost? Needing more control over deployments? Hiring a platform/DevOps person? Or did you get quite far without Kubernetes and realise you never actually needed it?
Dial
