how do I add abilities(Scripts/GameObjects) to my path finding agent

So you want to dynamically alter the behavior (of how a gameobject moves) of a class at run-time. there's a couple of solid design patterns for this.

The Strategy pattern is a simple pattern to implement. you have a class that publicly stores a reference to sub classes that it will run during an event. for example a Monobehaviour script has a public variable to an IMoveable interface with a function Move() that it will run in Update(). IMoveable could be a DefaultForwardMovement Class or a PathfindingMovement class that can be swapped out at runtime. The pattern is pretty simple and straight forward to implement. and should be a pretty simple concept to grasp

The State Machine Pattern is nearly identical to the Strategy pattern, except that the IMoveable references aren't publicly available, but internally managed. This is ideal if you want the Gameobject to strongly control when and how it will change its movement behaviour.

The Decorator design pattern is great if you want to partially override a object behaviour over different lifecycles (say that a ship is now using a pathfinding agent due for some special event, but keep using it's default movespeed, while a 2nd effect jammed the rudder and it can't turn). its also great for stacking overridden behaviors together. Decorators are a lot more flexible, but also much more complicated

first off make a mediator class, a MovementBehaviour class that derives from Monobehaviour. whose sole purpose is to allow other monobehaviour classes indirect access to a stable reference (so they don't need to worry about broken references when a decorator is swapped).When an outside class tries to call Move() on the MovementBehaviour class, the class will call the Move() function for the current decorator that's active (either to move straight forward, or to follow a Navagent).

with the decorator pattern you write a concrete class that will perform some default action when a class calls that action to be done. but then you can have a decorator that can wrap around the concrete class and pretend to be that class that will run the actions (but will be doing something different. this decorator class will keep a reference to the class its wrapping for when some value thats not specific to the decorator is needed (such as a move speed for a pathfinding decorator) by grabbing it from the class its wrapping. and decorators can wrap other decorators stacking effects together

Any of these options are usable, just that some will be better fit for your game than others, depending on what your specific requirements are. if you believe that you'll only have those two movement modes, then just any straightforward technique should do (tho I recommend against it)