FWIW, I have all this data backed up elsewhere. I just wanted to see if Fibery AI was at all useful. Its been a slog to get value from it.
Most notable mistake: I gave it a CSV with a precise list of duplicate data to remove from a Fibery database, and despite it making me repeat at least three times what the specific deletion criteria was (even though it should have been obvious that it simply needed to match the CSV data fields to locate duplicates), it still turned around and completely violated the very rules it demanded I specify. Wild.
The cherry on top was that it then contradicted itself regarding how many extra rows got deleted. (I’m not included the contradicting message for sake of brevity.)
If the Fibery AI hallucinates this badly, why even include it?
Another scary one. I will ask Fibery AI if it can do something, and instead of telling me yes or no, it just does it! For example, I asked this question and it began the conversion. 
Hi!
I am Max, one of the devs behind the Fibery AI. Thanks for posting these issues, I’m sorry you had such a bad experience, it sucks indeed. I’ve investigated all of the issues and why they happened, so, let me respond to each one by one:
-
Agent suggested plan 3 times and never executed it. Agent was worked while UI was in Architect mode. Then, after a certain message, UI’s mode changed to non-Architect, and it has influence on what agent is able to perform (mainly, agent is unable to perform any update in non-Architect mode). We do have mechanisms to inform about the incorrect mode for the prompt user has asked, but in your specific case it did not fire. Most probably, because of the long conversation, it was not triggered correctly. It is something we will fix.
-
Agent removed more rows than in CSV. So, in your request, you asked for de-duplication of rows. The agent actually started correctly: it matched the CSV the right way (one database row per CSV row), reported 196 matches. Then the bulk delete failed with a low-level error — “statement affected 195 rows, but 196 was expected.”. The cause was the following: one transaction existed in your database in four copies, which produced a duplicate ID in the deletion list, and our delete API treats that as a failure and rolls the whole thing back instead of just ignoring it. That error is what made agent delete more rows. Instead of retrying the exact 196 IDs, the agent re-ran the matching and removed some records. After some duplicates were deleted, the same Date+Description+Amount criteria matched the surviving originals.
We will change the rules of deletion of entities, and will not fail the batch if some ids are duplicated, and simply inform the agent about which ones failed.
-
The contradictory numbers (246 total vs 196 extra). The first answer was computed from an incomplete page of the deletion history; the second one was correct, and was provided by another (more capable) model. So, the first message is the aftermath of the collapse because of the way how deleteEntities tool behaved. Unfortunately, models still may hallucinate, especially in the cases when they don’t know what to do or face unknown conditions. We minimize these conditions as much as possible, but they still may arise.
-
Agreed, it shouldn’t have done that. We will tweak prompts for that case, as well.
Again, very sorry you’ve had these issues, and very thankful for your feedback 
I appreciate your response and hope that my feedback does result in better instruction files for the Fibery AI to follow. In the mean time, we’ve connected Fibery via the API to CADSharp’s own Codex-powered agent, which we command through PowerShell.
Overall we’re quite happy with Fibery. We have replaced at least six other softwares. Our entire business is effectively in Fibery now. Kseniya was impressed during her review.
