If you have constant and regular changes in priorities that appears to be an issue with whoever is doing the prioritizing/planning for your team and not a consequence of a specific process.
Without sprints, when the next semi-important bug comes down from production, its pretty hard to justify that its more important than the feature you are building, or especially the tech debt cleanup you are doing. Everything tends to be "important" so if there is no culture of picking a set of work and sticking to it, attention is constantly distracted from one thing to the next.
For me at least, programming is all about some momentum - its hard to get rolling but once you are, you can keep going. Sprints give me the room to have bouts of momentum, stopping every two weeks to adjust direction, and then starting up again. Without them, it feels more like pacman - darting and reacting rather than holding a steady direction.
Ideally, at the end of a sprint you'll have a concrete deliverable. Because this deliverable is concrete and not ongoing, the team should (theoretically) be able to switch entirely to a different project (or priority) afterward when business circumstances demand it.
That's where the "agility" comes in. If, on the other hand, the work is being produced as a continuous flow--without hard cut-offs--then there's no set point where the team can switch priorities without leaving behind a half-finished state.
Obviously, YMMV on how this all shakes out in practice.