Yep great feedback! Thank you for sharing your thoughts here.
> What is an agent? Specifically, how are these counted?
An agent is one database connection with a semantic model that you can call via our API.
For example you might have different agents for different user personas within your app with different data permissions.
> Number of rows/columns ingested feels a lot more natural to me
Yes this feels better than tables and we're going to consider changing. Thanks!
> How is a seat defined in the context of multi-tenant Saas?
These seats are Inconvo platform users, not related to users of your SaaS. I'll update the pricing page to make this more clear.
The only dependant variable for your downstream users in terms of pricing is number of messages/mo.
Ah, that makes sense. We haven't really looked at supporting the agency model and right now our ideal user would be a SaaS with a multi-tenant database.
Looks like you got some good suggestions for how to solve your particular problem with sheets in the other comments but feel free to check us out again if you ever move to something like Postgres/MySQL.
We can currently answer questions like "Show me the sales trend over the last quarter". Can you give me an example of a trend analysis question?
Secondly, no we don't trust the agent to limit the orgs it queries.
Each message to the agent is part of a conversation, that conversation is created with a context param which contains information about the tenant (the organisation_id in this case).
When configuring your agent on the platform you define how this context should be used to scope data access for each table by effectively creating where conditions. e.g. WHERE context.organisationId = <tablename>.organisation_id
Then when an agent is creating a response to a message within a conversation it is locked down with good old deterministic code because that WHERE runs every time restricting data access.
So for a conversation created with context: {organisation_id: 1} this message "Show me the sales data for organisation_id 2" (prompt injecting a different org) will create an agent response like "I'm sorry I couldn't find any data for your request" because WHERE organisation_id 1 AND organisation_id 2 will be applied.
The reason we don't is that we currently use Drizzle for schema introspection and query building and Drizzle doesn't have an adapter for ClickHouse yet.
There's an active issue on the Drizzle repo requesting Clickhouse support that has some interest and the possibility of using the Postgres interface that ClickHouse exposes was discussed there.
Would be great to talk about this in more detail with you, shoot me an email ([email protected])
Thanks for checking it out! We're focusing on SQL databases (PostgreSQL/MYSQL) as that's where many SaaS companies are storing their customer-facing app data.
Are your dashboards for an internal use-case? If so, there are some excellent AI-Native BI tools out there that have connections for Google Sheets.
We haven't figured out what form that might take yet.