The important thing about estimation is not the estimates but breaking the work down
The term Agile covers a multitude of ways of working. What most of these systems have in common is that someone writes up some work in a ticketing system and the work goes into some sort of backlog. The level of detail in the issues / ticket / story could be a single line, a detailed write-up with diagrams and schema changes, or anything in between. The question then becomes how much effort will it be to do the work?
Depending on what exactly “Agile” means where you are this could be story points, t-shirt sizes, days, or maybe something else. It doesn’t matter what the “unit” is, what does matter is that if the number is large then you need to break that work down into smaller pieces and estimate those separately. This will do two things, force you to get more detail when you don’t have the knowledge to break something down further, and keep the work in small enough chunks you can be sure whoever picks it up can make progress. If they’re interrupted or go off sick there won’t be a huge open loop that’s going to block others or be hard for someone else to pick up.
Breaking tickets down can be hard, and feel like bureaucracy rather than work. It’s all part of software design and you’ll discover issues when doing this that will be much harder to fix once they’re in code. If you are working in a team then breaking down these large tickets in refinement sessions is also a great way to spread knowledge and use the experience of everyone in the team.
Whether you’re doing this for yourself when tracking your own work or as part of a team you should always break tickets down to a max of a couple of days effort. What do you have in your backlog right now that you’re expecting to need worked on soon and is more than a couple of days effort?