Agile is often described as "only do what you need to do now, and you can refactor later if more things are needed".
This is rather misleading. It can be read as "bodge something in quickly now, and then work out how to upgrade it to do more things in the future". Which will lead to a world of pain and technical debt.
For any system you need a design. For small/simple systems this design can be in your head, but you still need to think before you start about what the system will do, and how best to do it.
So IMHO the correct way to include design into an Agile approach is to design enough now that you know what the system is ultimately expected to do, and broad strokes describing how it will do it. Come up with a flexible enough design that you don't burn any bridges. But don't waste time writing a formal detailed specification for every nut and bolt. Design down to a level where you know where and how a subsystem will fit in, but it can be treated as a "black box" that in itself can be designed only when you need to implement it.
Agile development shouldn't exclude a formal architecture - it just means that you should only design enough of the formal architecture that all the bits will fit together well when you are finished, and you flesh out the smaller details of that design only as and when they are needed. Sometimes that means you still need a fairly detailed design up front.