# 🔮 Fibery's take on AI (vision) **URL:** \ **Category:** News & Announcements\ **Created:** [March 6, 2026, 1:52pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503 "2026-03-06T13:52:02Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [March 6, 2026, 1:52pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/1 "2026-03-06T13:52:02Z")
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](https://openclaw.ai/)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**. 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. ### 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: 2. We will **add mechanisms in Fibery to control, review, reject, accept and undo changes done by Agents** (and by humans). It includes: 3. We will improve Fibery Flexible Domain to **support connected data even better** : ## 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. ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [March 6, 2026, 1:52pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/2 "2026-03-06T13:52:13Z")
---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [March 8, 2026, 7:32pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/3 "2026-03-08T19:32:49Z")
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](https://airtable.com/developers/web/guides/oauth-integrations), [Asana](https://developers.asana.com/docs/oauth), [Clickup](https://developer.clickup.com/docs/authentication) 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! ---
**Author:** ![Sergey\_Truhtanov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/sergey_truhtanov/32/13986_2.png) [@Sergey\_Truhtanov](https://community.fibery.io/u/Sergey_Truhtanov)\ **Post date:** [March 9, 2026, 9:45am UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/4 "2026-03-09T09:45:43Z")
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. ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [March 9, 2026, 11:46am UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/5 "2026-03-09T11:46:19Z")
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](http://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. ---
**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\ **Post date:** [March 9, 2026, 12:37pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/6 "2026-03-09T12:37:54Z")
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. ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [March 9, 2026, 1:40pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/7 "2026-03-09T13:40:33Z")
## 💭 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](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-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. ```json // 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](https://techcrunch.com/2025/03/26/openai-adopts-rival-anthropics-standard-for-connecting-ai-models-to-data) and [others](https://www.theverge.com/ai-artificial-intelligence/841156/ai-companies-aaif-anthropic-mcp-model-context-protocol) 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. ---
**Author:** ![PsyRoelofs](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/psyroelofs/32/7163_2.png) [@PsyRoelofs](https://community.fibery.io/u/PsyRoelofs)\ **Post date:** [March 9, 2026, 2:00pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/8 "2026-03-09T14:00:26Z")
> 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? ---
**Author:** ![christamae](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/christamae/32/13729_2.png) [@christamae](https://community.fibery.io/u/christamae)\ **Post date:** [March 9, 2026, 5:18pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/9 "2026-03-09T17:18:55Z")
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! ---
**Author:** ![Mark\_Bayly](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mark_bayly/32/12341_2.png) [@Mark\_Bayly](https://community.fibery.io/u/Mark_Bayly)\ **Post date:** [March 14, 2026, 7:01am UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/10 "2026-03-14T07:01:39Z")
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. ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [March 14, 2026, 11:42am UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/11 "2026-03-14T11:42:23Z")
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 ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [March 17, 2026, 12:37pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/12 "2026-03-17T12:37:23Z")
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. ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [March 17, 2026, 12:38pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/13 "2026-03-17T12:38:24Z")
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. ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [March 17, 2026, 12:41pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/14 "2026-03-17T12:41:17Z")
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. ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [March 17, 2026, 1:22pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/15 "2026-03-17T13:22:00Z")
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)](https://www.ibm.com/think/topics/react-agent) approach of Claude Chat’s MCP use, to the more [Plan an Execute](https://blog.langchain.com/plan-and-execute-agents/) 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. ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [March 17, 2026, 1:28pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/16 "2026-03-17T13:28:28Z")
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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 17, 2026, 2:58pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/17 "2026-03-17T14:58:26Z")
> [@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)](https://community.fibery.io/t/granular-ai-access-control-space-level-ai-permissions/10580/5): > > 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… ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [March 23, 2026, 12:49pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/18 "2026-03-23T12:49:20Z")
Allow MCP to read and edit automations Allow MCP to use the # linking to create simple links between written text and an entity ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [March 23, 2026, 1:26pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/19 "2026-03-23T13:26:35Z")
**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](https://www.sunsama.com/) (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. ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [March 23, 2026, 1:36pm UTC](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503/20 "2026-03-23T13:36:40Z")
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. [Next page](https://community.fibery.io/t/fiberys-take-on-ai-vision/10503.md?page=2)