🔮 Fibery's take on AI (vision)

[mdubakov]

We’ve been trying many things with AI at Fibery during the last three years. Some of them worked, some of them failed. Here is our take on Fibery + AI and the whole industry.

AI future bets

1. Autonomous agents that can produce some value will appear in 2026 or 2027. Right now we already have some relatively dumb but quite autonomous agents. Most likely, smarter and more useful agents will be there soon.
2. Humans and Agents will co-exist for some future (~10 years? Forever? who knows).

Fibery future bets

1. Fibery is Operating system for orgs run by nerds. We believe in near future operating system for orgs should also include external Agents. And we believe that nerds will become Agents early adopters.

2. We believe Fibery is perfectly positioned to be a place where Humans and Agents collaborate to get things done.

   • Fibery has flexible domain that connects databases via relations or bi-directional links, and supports rich text content, so it can be configured and evolved to almost any domain and use case.
   • Fibery is mendable. Agents and humans are be able to build own solutions to work more efficiently.
   • Fibery has one of the most advanced permissions model on the market. It will help to isolate Agents context.

3. We bet on external AI Agents. We think that other vendors (Anthropic? OpenAI? …) have 100x better potential and resources to build AI Agents than we do, so we will not spend significant time on Fibery internal agents.

   • We will keep Fibery Agents for getting started for sure. There are chances that Agents implementation will be unified and it will be not so hard to have less powerful but good enough internal agent as well.

What we will work on in the future

1. We will open up Fibery to the External Agents and make Fibery as easy to use for them as possible. We bet that Claude Cowork or similar things will beat internal agents (like Notion Agents) eventually. It means we will work on:

   • MCP Server with ~100+ tools to do anything with Fibery, including querying, searching, creating, updating and configuring all the things.
   • Any other ways to provide all the tools more efficiently (CLI, …). Overall, if you have tools it is not hard to wrap them up into the new shells. It also the reason why we will keep Fibery Agent inside. It will help new users with getting started and building things.
   • Native support of external Agents. There will be new abstraction in Fibery that will work like User in general. You will be able to setup new external agents and communicate with them from Fibery.

2. We will add mechanisms in Fibery to control, review, reject, accept and undo changes done by Agents (and by humans). It includes:

   • Changes of every object in Fibery will be saved (including Databases, Views, Formulas, Rules, etc)
   • Undo of any object will be possible
   • Versions diffs with approvals, including text and structural diffs (Agent wants to make 23 changes in 12 tasks and projects, review them) will be added eventually

3. We will improve Fibery Flexible Domain to support connected data even better:

   • Finalize permissions theme
   • Great search
   • Improve auto-relations
   • Support multi-relations
   • Better formulas
   • etc.

TLDR

We believe agents will become real contributors to organizational work. For years, humans and agents will coexist. Fibery’s role is not to build the smartest agent, but to become the best environment for humans and external agents to work together safely and effectively. We will make Fibery deeply usable for agents, while giving humans the visibility and control needed to trust the results.

[Sev]

What a wonderful read! Well done. I agree with every single point, but some really stand out.

@mdubakov

Fibery has one of the most advanced permissions model on the market. It will help to isolate Agents context.

Yes! Absolutely.

Just a few little reminders for the road:

1. To cover broad use cases we need two types of access for Agents:
   • End-user OAuth with authorization_code grant type.
   • Agent/service-user OAuth with client_credentials grant type.
2. The problem is that OAuth is right now managed by Fibery, but we would need a Self-Service Custom OAuth App Registration for the workspace just like AirTable, Asana, Clickup and many more, to let each app have its own worksapce-level redirect_uri, client_id and client_secret. This would allow access from agents with account-level custom redirect_uris, and would not need the current situation of a whitelist managed by Fibery.

@mdubakov

Native support of external Agents.

Love it! That does not need to be reinvented from scratch; it is still being perfected by the inventors.

@mdubakov

We will add mechanisms in Fibery to control, review, reject, accept and undo changes done by Agents (and by humans).

Essential, since not all agent platforms treat destructive behaviour with the same guardrails. Bravísimo for considering it!

[Sergey_Truhtanov]

Hello.

Can you please describe use-cases where both oauth flows are needed?

MCP protocol solves authentication. So external agent is able to access Fibery using it’s mcp. Only as a Fibery User though. But this exact problem can be tackled in different ways.

[Sev]

Hi @Sergey_Truhtanov,

@Sergey_Truhtanov

MCP protocol solves authentication. So external agent is able to access Fibery using it’s mcp. Only as a Fibery User though. But this exact problem can be tackled in different ways.

Yes, but with the current managed (by Fibery) OAuth, some external agents such as for example RunBear.io cannot complete their end-user OAuth flow, since there is no way to whitelist the account-specific redirect_uri that RunBear issues for each account. For this a self-service OAuth is necessary like Airtable, etc. which I referenced in the previous post.

@Sergey_Truhtanov

Can you please describe use-cases where both oauth flows are needed?

As for the Client Credentials OAuth flow, I mentioned it, because of this line in Michael’s message:

@mdubakov

Native support of external Agents. There will be new abstraction in Fibery that will work like User in general. You will be able to setup new external agents and communicate with them from Fibery.

If agents will be user-like entities, which is great, I presume they will be service accounts as their own principals (subjects) in the permission system. Being a non-human principal, the authorization_code OAuth flow would not work for them.

I like this new layer of auth, since an agent’s access could be limited by an architect in Fibery, even if the end-user using the agent has broader access. This would make agents less risky in some cases.

But to implement this, I am not sure how a service account agent would determine if the user can access it, which makes me think that while being a principal, the agent service account must also be a resource in the permission system, just like any entity type is now. This way, Fibery architects would be able to implement hard guardrails of agent use by users.

Now, this is the part where it gets interesting:

If we force agents to always authenticate the end-user, we would miss out on public-facing agents. And since you are building a full permission system and full change control/log for agents, presumably a public agent would be simple to set up.

But if we allow the external architect of the agent in the external system to authenticate the agent’s Fibery service account through the client_credentials flow, then the agent can decide whether to authenticate the end user through the authorization_code flow during use, or if it can just act as its own service account, all based on permissions set up in Fibery.

Example use cases for agent-only auth

In these cases, the agent acts as itself (NOT on behalf of a Fibery end-user) with client_credentials OAuth flow:

• Customer service agent: A public user identifies themselves with their order ID and email, and an agent verifies them against the CRM entities in Fibery, then answers questions about their specific order. CRM contact entries themselves could become principals of low-grade auth with order_id/email for example, but I digress.
• Lead agent: a public user submits a pricing inquiry, an agent interviews them, researches them externally, creates a qualified opportunity in Fibery, and assigns it to the most available sales rep.
• Roadmap agent: a public user asks agent when a feature ships, the agent answers, then asks about their use cases and either amends an existing feature request or creates a new one for review, or leaves things unchanged if the use case existed.
• Or an external permission system: where simply the external architect wants to limit access to an agent in the external system, regardless of Fibery, e.g. a secure team communications system where the agent gives reports on company financials, and access to the bot is limited using permissions in that external system.

[RonMakesSystems]

This is lovely, I’m gonna be playing around with Fibery AI Agents for sure this week.

I’ve raised this with Anton in the past, but one thing I find problematic is that there’s a lot of data that Fibery things is public (for all authenticated users in workspace), which I think should not be.

For example:

• Schema: Most users only see the spaces and databases they have access to since the ui hides the others, but in reality the full schema is accessible to all authenticated users.
• All entities in all databases. Even though the actual data in the entities is empty if you don’t have access, it does still show you the number of entities, creation date, and created by. Again, it’s hidden in the UI, but available via api and to ai agents. This is an even bigger problem when it has relations to entities which you DO have access to, since you can see those relations even when you don’t have access to the actual entity.

These aren’t huge problems when the UI is hiding these things for users, but for AI Agents it actually still adds a lot more context than it needs. If I only give the agent permission to one space, it doesn’t need to know about all others that exist in the workspace.

Everything in here though is fantastic and I’m really looking forward to it. Just mentioning this point since I didn’t see it addressed above.

[Sev]

On Agent Skills

Thinking out loudly with logical ramblings and a speculative finish .

My understanding of “fewer, broader agents”

Many current agents are paradoxically more constrained than humans since one agent does one or more similar/related jobs, or delegates to other agents in order to be able to do many different jobs. But since a skilled human can naturally adapt their role to context, I imagine the future of AI agents is that they will be able to go beyond a one singular skilled human, and handle widely varying jobs themselves.

I considered my theory validated at least by Anthropic, when they announced the concept of Skills. They seeming to be heading towards fewer, broader agents that select the right roles dynamically based on input, which already existed in the form of MCP Tools, but Skills seem to group knowledge and Tools together in a more cohesive way, though in the end I do not see how they are different from a free-form textual MCP tool.

The distinction between a sub-agent and a skill

• Sub-agent: the main agent delegates (hands off) the task, and the sub-agent executes it in its own context.
• Skill: the main agent uses the skill inline, reasons with it internally, and executes using the skill within its own context.

The distinction matters, because:

• A sub-agent has its own execution context, which means it has its own permissions.
• A skill has no separate execution context, which means it shares the same permissions as the main agent.

Assumption of a “strictly”-skilled future

I believe an agent’s “Skilled use of a tool” may become more popular, plausibly making Skills an integral part of MCP. Think “Agent calls tool X as a Y” e.g. “Agent calls create_entity as a Project Manager” vs. “Agent calls create_entity as a Data Analyst”.

If this gets widely adopted in agent architecture, then agent-toolset permissions may not be enough/ideal, in favour of agent-toolset-skillset permissions.

// So instead this tool call from a "project manager" sub-agent:
{ "tool": "create_entity", "args": { ... } }

// We may receive this one from the main agent:
{ "tool": "create_entity", "skills": ["project_manager","policy_enforcer", "damage_guardian"], "args": { ... } }

And if this get implemented more strictly in the agentic architecture (see my ramblings below), it may mean the same agent skilled as “project_manager, policy_enforcer and damage_guardian” should be allowed to create/update/maybe-even-delete tasks, but skilled as “business_analyst” should only be allowed to only read tasks.

This is the agentic rough equivalent of composite OAuth scopes i.e. not just what the agent is calling e.g. “tasks:write”, but also in what capacity e.g. “tasks:write@project_manager”.

Implications for Fibery’s agent permissions

Of course, Skills are not part of the MCP spec (at least not yet), which makes an agent-toolset-skillset permission model speculative. But if Anthropic sets the trend like it did with MCP e.g. when OpenAI and others adopted it, and Skills become a standard part of agentic architecture and MCP, then it is likely that preemptively designing for agent-toolset-skillset permissions will prove to have been a good idea.

So, I wonder, if you should just design for an agent-toolset-skillset model, but with a the default skill of “self”, which would be the equivalent of the current agent-toolset model, and then if/when Skills become implemented as a standard, you are ahead of others that did not keep them in mind.

[PsyRoelofs]

We will add mechanisms in Fibery to control, review, reject, accept and undo changes done by Agents (and by humans).

For me this is the biggest, only, obstacle for using agents in production.

As a nerd, I can write API integrations, I can hook up external agents myself - I don’t need or want internal agents as much because I want to have control over the budget and model being used. Both OpenAI and Anthropic offer GUI based agent interfaces with MCP support so I can do most there.
I can also define the auto-relations etc in my agent interactions.

But mass undo - I can get nowhere now, except if I keep things (semi-) local.
It terrifies me to unleash agents to my team without a big undo button.

It is the primary reason why parts of our company have moved to offline markdown/git based flows. The power that agents provide is just tremendous, but the need to be able to audit and revert things done by agents is just to great.

@mdubakov What is your vision on this w.r.t. priorities?

[christamae]

I just connected the MCP server to Cursor, and it’s already a much better experience than using Fibery’s native AI for building project plans or extracting insights from meeting notes.

My overall AI workflow is coming together quickly, so this is a huge win for me—thanks!

[Mark_Bayly]

My experience is that the connected MCP server is really slow at updating anything. Much better working with the internal ai agents. Using Claude through the MCP server is frustrating because Claude knows very little about Fibery’s latest capabilities and ui, so it is always guessing what to do and even what the data is. I always have to double check. I’m using it to help me write the prompts for Fibery Ai and then verifying what Fibery is has implemented to see if the prompt has worked. I tried using the browser connection so Claude could see the screen and operate through the browser. But it has absolutely no idea how the ui works. It’s the most frustrating experience I have had for a long time watching it guess like a 3 year old what to try in the ui.

It also has no idea how to write the formula. I use it to create the short char. limited prompt (it struggles to do this!) for the Fibery formula ai. The formula ai definitely needs to be kept.

For my part, please keep your internal tools developed and working. The external connections are just nowhere near good enough. Of course, if I am using the connection incorrectly, please let me know. My experience is non technical.

[mdubakov]

You are absolutely right about current state of Fibery MCP. Many of these problems will be fixed in nearest future. With more tools Claude will know more about Fibery and be able to do everything that our internal agent can do (create formulas, views, spaces, etc).

MCP has other problems, like tools discoverability and large context usage, but I guess they will be resolved pretty soon, there are new approaches appearing that give us hope.

Overall, MCP is just a transport. If you use Claude Desktop it is way better to deliver all Fibery tools via console app, it will be more efficient and fast, that is also something we are considering.

Internal agent will not be deprecated, and it will be evolved as well, but with less focus for now. We will see how it goes in ~1 month and may reconsider this for sure

[Lee_Denny]

Allow external AI to see comments on rich text (and maybe even reply).

Use case: AI creates a document for me, i want to give feedback for next iteration, easiest way to do that is leave comments on the sections as i read through, but currently AI cannot see those comments.

[Lee_Denny]

Separate me and AI. Currently AI makes a change using MCP but that change is attributed to me as a user. I think it is really important to be able to see what is AI and what is genuine human.

[Lee_Denny]

Invoke AI from inside fibery.

In slack you can @claude to get it to work on something. It would be great to do this from inside fibery too.

[Sev]

Hi @Mark_Bayly. It is true that external AI knows less about Fibery and our data, and therefore can do long loops of trial and error to do things.

In our case, we have realised that using instruction we could convert the ReAct (Reason->Act loop) approach of Claude Chat’s MCP use, to the more Plan an Execute approach of Claude Code/Cowork to reduce the trial-and-error loops due to this lack of knowledge about our data and Fibery.

Claude Skills to the Rescue

To achieve the above, we have found that adding a Claude.ai skill has helped a lot to:

1. enforce certain data handling procedures, by making the agent check if something exists before creating it.
2. reduce mcp update/create call loops de to incorrect syntax, by making the agent check schema and guide before making calls.
3. batch mcp create/update, by making the agent think through the entire operation thoroughly before making create, update or delete calls, etc.
4. enforce certain business rules to help the agent carry out the procedures in the correct order and place.
5. enforce semantic inference rules to efficiently and correctly map non-technical user input into Fibery data.

Results

Doing this, we have been able to (at least during testing) reduce MCP calls drastically.

For example for one operation that requires the creation and interlinking of 8 entities across 5 different types (databases), using plain English user input such as “create a booking from this conversation” and giving it the email or slack thread:

• It went from over 50 read/write calls
• To half: 25 (i.e. 15 read calls and only 10 write/update calls).

If you wish, send me a direct message and I will share the Claude Skill I created, which is still a work in progress.

[Lee_Denny]

Allow AI to see usage metrics/analytics inside our workspace so it can see which views are used and which are not, see search logs, see how our internal users are interacting with our setup etc to try and find improvements for us.

[Chr1sG]

@Lee_Denny

Separate me and AI. Currently AI makes a change using MCP but that change is attributed to me as a user. I think it is really important to be able to see what is AI and what is genuine human.

Granular AI Access Control (Space-level AI Permissions)

I think we should consider introducing the concept of AI agents as additional users in the workspace, potentially each under control of a human user. In other words, admins/architects can define what access each (human) user is allowed, and then any user can create ‘delegate AI’ users. By default, the AI users get the the same permissions as their human master, but the user also has the option of restricting them, e.g. making one of the AI delegates a read-only agent, making another limited to…

[Lee_Denny]

Allow MCP to read and edit automations
Allow MCP to use the # linking to create simple links between written text and an entity

[Lee_Denny]

Use AI To Speed Up Human UI/UX Improvements

As well as making Fibery great for agents to use, I think it is really important that you use AI to speed up your development on all of the UI/UX features that our non-technical end users want to make their lives better.

You have a great cadence of releasing features, but the new paradigm of what is possible with a fully flexible tech stack and claude code, means that end-users patience to wait for features is getting strained.

I very much see Fibery as the hub between our AI agents and our humans and it needs to be a slick beautiful experience for both of them for it to retain that position.

Example (Sunsama)

For individuals to plan our time effectively we used to use Sunsama (using clickup integration).

Since we moved to Fibery we have not been able to use it. It has had a big impact. The options to try and solve this have suboptimal outcomes.

• Zapier: difficult to setup and manage to try and achieve 2-way sync. Zaps break often meaning data not aligned.
• Custom web app with Fibery as backend: UI is completely separate from where we are telling our team to focus on for all their work and from their other views. If we do this, why not move all views to the custom app, and then probably Fibery isnt the best backend?
• Recreate within Fibery databases: cant establish drag and drop behaviours, cant tweak UI layout, creates a lot of complexity for users with extra fields.

A proper solution needs one of the following:

• Fibery to recreate the sunsama view it within their UI
• Fibery create a sandboxed UI builder where we can somehow use AI to create a view with pure code without any of the current limitations on how to display and manipulate data
• Fibery create a 2-way sync with Sunsama

It’s the kind of thing that we feel completely blocked from solving at the moment, and an example where i know others have tried workarounds too.

Other examples from our team that were mentioned last week include bidirectional sync for google calendar and ability to display colours in rich text fields. Im sure there are many more in the community backlog too.

All shared from a place of love for Fibery and wanting you to succeed big.

[Lee_Denny]

AI Model Costs

Approach in our business is to let our team have as many AI tokens as they want during this wild transition. I dont want them held back from trying anything or getting help with their work.

If concerns around costs of model use is holding back any Fibery feature requests (such as letting AI access files) then we would rather you switched back to the old model of us providing our API keys and paying for our own model usage to get the features out and remove the productivity blockers.