Start with a non-actor interface and see if it works for you.
Sometimes eliminating states reduces a certain functionality to a single entry point meaning that you don't need an actor, you just need a standalone async function. nkbelov's comment is a great illustration of that, i.e. if
func loadImage(at: URL, addingTags: [String], saveToDisk: Bool) async throws
is all you have then declare it as a static function and there will be no need for an actor altogether. In fact network calls backed by URLRequest are almost always purely functional and don't require any states or actors (unless you use local caching but that's a different story).
In general, the functional approach is a lot more concurrency-friendly, i.e. when you move your state to the stack.
I'm still not entirely sure if I know exactly when to use actors in client apps. At first glance you use them when you have a state that can be accessed from more than one execution thread.
Most of the time though you don't have additional execution threads in your client app unless either (1) you create them because you want something to happen in parallel with your UI, or (2) the OS forces you to, usually via hardware related API's, such as camera or audio.
For example I've been struggling with this - [Concurrency] Actors and Audio Units, now trying to rewrite my audio engine for Swift 5.10/6 and it's still not clear whether I should use actors and how. I'll probably come back to the forum with some new questions.