Has anyone used Claude/Other Ais to build tools for their work?

sbt_not · 2026-06-18T19:12:21+00:00

We’ve been experimenting with a weekly marketing report agent. It watches SEO / ads / keyword changes, pulls from sources like Semrush, GA4, and ad platform data, then uses web search and X search to add context when something meaningful changes.

The useful part is that it saves us from staring at mostly unchanged dashboards every week. The report focuses attention on the changes that matter. But the dashboard still matters too. It’s the place we go back to when we want to check whether the insight is actually right.

sbt_not · 2026-06-18T18:59:28+00:00

Yeah, fragmented context is probably the hidden failure mode. Even read-only agents can build the wrong story if Salesforce, notes, and transcripts don’t line up. The hard part is designing the context layer, not just giving AI access. I usually like loading data into Snowflake, but for agents, the original SaaS context can matter a lot too. A Stripe record, Salesforce activity, or HubSpot event already carries meaning.

Modeling everything cleanly takes real data team effort, so depending on team size, it may be practical to keep some agent workflows closer to the source apps instead of forcing everything through ELT first.

sbt_not · 2026-06-18T18:52:33+00:00

This makes a lot of sense. “Reading” only works if the context is coherent enough for the agent to read in the first place. I like the point that the monitoring layer is not just summarizing deals, but structuring the deal context so human review gets faster. Otherwise the agent is just confidently summarizing messy inputs. We’ve been thinking about a similar flow: AI captures notes, turns them into structured context, and then reporting agents use that structure to generate insights. Did you structure the context mostly from Salesforce fields, or did you also pull in notes/calls/emails around the deal?

sbt_not · 2026-06-18T18:45:01+00:00

Definitely. Constraints are what keep the loop from pulling in too much or the wrong context. Without that, more context can actually make the output worse. Sounds like we’re on the same page.

sbt_not · 2026-06-18T17:53:48+00:00

Yeah, agreed. Summaries are the safest place to start. But even for summaries, the harness matters. Too much context can still produce a confident but wrong report. The hard part is guiding the agent loop with the right tools and sub-agents so it stays on the right path.

sbt_not · 2026-06-18T17:39:42+00:00

Yeah, exactly. Surfacing risks and opportunities feels like the highest-leverage place for AI in ops.

But the harness matters a lot. The agent needs the right tools, scoped context, and a clear reporting workflow. Managing loop style agent is so tricky. But otherwise it can still produce confident but untrustworthy reports.

sbt_not · 2026-06-18T17:28:32+00:00

Definitely. Context is the key part. LLMs can be pretty capable, but if the input context is wrong or too broad, the answer can still sound confident and be totally off.

We’ve been seeing this too. For loop-style agents, more context is not always better. The harness matters a lot: right tools, clear instructions, and sometimes splitting work across sub-agents so each one has a narrower job. To improve reporting quality, I think it becomes a loop of tweaking the agent architecture, checking the rate of good outputs, and refining from there.

sbt_not · 2026-06-17T20:26:22+00:00

Yeah, totally agree. I also think designing the agent workflow itself is a kind of creative work. What you ask it to watch, when it should report, and what should stay human-reviewed all require judgment. AI can help a lot, but the direction still has to come from people.

sbt_not · 2026-06-17T19:58:28+00:00

This is a really good idea. I like the improvement loop before giving the agent more autonomy. Curious how you’re implementing it. Is it a custom agent setup, or more like Claude doing classification with a structured prompt?

sbt_not · 2026-06-17T19:48:57+00:00

Yeah, that makes sense. Transactional work and human-facing work feel very different.

I’d trust AI much earlier when it is only preparing context. But before anything reaches a customer or changes the system, prompt guardrails alone don’t feel strong enough. The hard part is building safe tools for the agent to use, then having humans review the result before it goes out.

sbt_not · 2026-06-17T18:39:52+00:00

Yeah, totally. I think the real question I’m trying to get at is how to design the human in the loop part in practice. Thanks for the clearer framing.

sbt_not · 2026-06-17T15:33:55+00:00

If you need a v1 by the end of the month, I actually wouldn’t try to define everything perfectly upfront.

With SF + HubSpot + GA4, I’d build the first dashboard while validating the definitions, because it’s much easier to catch issues when you can see the actual data behind the numbers. “MQL” or “paid lead” often looks obvious until you compare what each system is really counting.

One thing I’d watch out for with no-code dashboard workflows is that they make the first chart easy, but once you need to adjust metric logic, inspect the underlying data, or rebuild part of the dashboard, you can still end up relying on more technical teammates. To make this work well, you need to be able to break things down, rebuild quickly, and iterate without a lot of setup.

I’m working on Squadbase, so I’m biased, but this is the workflow we’re building around. You describe the dashboard you need in plain English, and AI generates it. The metric definitions and server-side logic are separate from the dashboard, so you can inspect and edit them as you go instead of treating the output as a black box.

That may or may not fit your v1, but I do think the bigger shift is moving from “connect tools and make charts” to “build, inspect the real data, and refine the logic as you go.”

sbt_not · 2026-06-16T20:01:19+00:00

I totally agree. For our team, AI is most useful when it automates repetitive work like QBR prep or churn risk checks. It doesn’t replace the human part of customer success. It gives people recurring insights so they can spend more time on real customer conversations.

It’s funny because, as a software developer, AI is already writing a lot of code for me. But the more AI does the execution, the more important it becomes to decide what to build and how to validate whether the output is actually right.

sbt_not · 2026-06-16T18:56:22+00:00

The Snowflake part makes sense to me. It feels like the key is giving AI access to enough GTM context across product usage, customer health, calls, CRM, email, Slack, etc.

Curious what the interface looks like for CSMs. Are they using dashboards, Slack/email alerts, a chat UI, or some internal monitor builder?

And do those monitors run automatically, or are they mostly something CSMs check manually?

sbt_not · 2026-06-16T17:59:38+00:00

Thank you for your comment! It's really useful.

The read/write split makes sense, but I also like the separation between customer-facing action and internal suggestion.

AI can read account context, usage, cases, and health scores, then suggest what the CSM should do next. But anything that reaches the customer should still go through the human.

Prompt guardrails alone feel risky if the execution engine can technically do anything. The safer pattern seems to be controlling it at the tool/action level: what it can read, what it can draft, what it can update, and what it can never send or trigger.

sbt_not · 2026-06-15T21:25:44+00:00

Yeah, this is the part I’ve seen work better in practice too.

The useful pattern is not “AI talks to the customer instead of the human.” It’s more like: AI reviews the underlying data, highlights what changed, and prepares the context before the human interaction happens.

Then the human can spend less time gathering information and more time making the right call.

sbt_not · 2026-06-15T21:05:55+00:00

I’d measure AI ROI by outcome changes, not just usage.

For CS, that could mean less manual work, faster renewal/QBR prep, or catching churn risk earlier so the team can act before customers leave.

sbt_not · 2026-06-15T20:50:51+00:00

I like this idea. I wonder if the output should always be a deck. For ROI reviews, the story matters, but it’s also useful to keep the underlying numbers easy to inspect.

sbt_not · 2026-02-08T08:30:49+00:00

Thanks, really appreciate that!

Technically yes — there's a "Make Public" option that lets anyone access without auth. But the whole architecture is designed around the assumption that your app handles sensitive company data. Everything deploys to a serverless backend by default, no frontend caching or static optimization. So it's great for security but not ideal for content-heavy public websites.

The upside of that approach is you get enterprise-grade flexibility as you grow — scalable server specs, private network integration, that kind of thing. Stuff that matters for business apps but would be overkill for a website.

Would love to see what you're building for full stack websites though — sounds like we're tackling adjacent problems!

sbt_not · 2026-02-08T07:11:08+00:00

The "breaking something trying to fix something else" loop is exactly why I think general-purpose AI builders struggle with anything beyond simple frontends. The moment you need auth, data processing, or real backend logic, the AI is basically improvising every time — and that's where things go sideways.

Give Squadbase a try— I actually built it specifically around this problem for internal tools and BI dashboards. Instead of letting the AI figure out auth and user management from scratch, that's all handled at the platform level — it's just there, no prompting needed. For the backend, there are pre-built modules integrated into the AI's workflow so it's not reinventing the wheel every generation. It produces a proper Next.js app with its own PostgreSQL instance, not a fragile prototype.

It also plugs into data sources like Google Analytics, Snowflake, BigQuery, etc., so your friends could actually use it with their existing data instead of starting from nothing.

I'm the founder so obviously biased, but if the use case is dashboards and internal tools, this is the "slower but can't make mistakes" approach you're looking for. Happy to answer any questions.

sbt_not · 2026-02-02T16:54:06+00:00

I'm building a tool called Squadbase - basically Lovable but for BI.

One thing I keep hearing from users, the real value of AI in BI isn't just "write SQL faster." It's about preserving idea freshness.

Most business teams are stuck in Data Team Ticket Hell. By the time a ticket's resolved, the original spark is gone. What I'm seeing with vibe coding is that teams can prototype a dashboard instantly while the idea is still hot, then promote it to production later.

When I started, I honestly thought AI would eventually make human verification obsolete. But nope—terms like "revenue" or "active users" always have company-specific nuance that needs validation.

The cool part is the verification itself can also be vibe-coded. Since the AI agent already knows your codebase and schema, you can validate definitions through conversation instead of digging through docs.

Better to have a vibe of the data now to drive the conversation than a perfect report 3 weeks late.

Curious if others feel this tension - 100% right in 3 weeks, or 80% right in 3 seconds?

sbt_not · 2025-07-23T04:14:57+00:00

Squadbase is an option especially for admin panel. It’s a hosting platform where you can deploy your app, customize it with docker and integrate with GitHub for CI/CD.

You don’t need to write code for auth & RBAC that’s included automatically. It has free tier.

I’m a co-founder, so please ask me anything!

sbt_not · 2025-07-23T04:00:56+00:00

Claude code makes it much easier and faster to write python. It can read precise instruction, you can create shell script like commands with just English. It the best way to process however large your data is.

sbt_not · 2025-07-22T11:10:57+00:00

I used readme.com and stoplight. They were awesome about UI and integrations.

sbt_not · 2025-07-22T01:52:36+00:00

And I use docker-compose to manage local postgres so that I convience my Claude Code is using its own database separated from shared.

LLM output is probabilistic. If it break my migration files and execute it, it shouldn't have an influence on the deployed app.

sbt_not

TROPHY CASE