Compared to the untyped version, Akka Typed takes a slightly different approach to define what an actor is.

In Akka untyped, an actor is any object that is a subclass of an abstract Actor and overrides a def receive: PartialFunction[Any, Unit] method. This allows the developer to do anything in the implementation except return a meaningful result, which makes it hard to reason about the code and impossible to combine actor logic.

Akka Typed declares that any well-defined behavior is a computation entity and thus can be declared to be an actor. The well-defined in terms of Akka Typed means anything that defines a statically typed Behavior. The type of Behavior limits actors to receiving messages of this specific type only. The return type of the actor's behavior is required to be the next Behavior of the same type with respect to inheritance. This way, it is possible to ensure at compile time that the actor will receive only messages of the type it declares to handle. 

In order to achieve this, actor addresses also need to be typed, and the type of address needs to be known at compile time. Hence, features of untyped Akka such as implicit access to the sender of the present message and general actor lookup are not available in typed Akka. By contrast, actor's addresses need to be defined as part of the protocol or need to be managed by an external (to the actor) facility.

Another notable change is the introduction of Signal message types, which represent events in the life cycle of an actor and replace dedicated callback methods that were exposed by the Actor class in untyped Akka. Although this is not a very big spot in a whole picture of changes, it is a good move to make the implementation of Akka's actor model closer to the abstract actor model.

In short, Akka Typed restricts actor communication and behavior to the model, which can then be type checked at compile time. This limits the developer's choices and possibilities for the implementation, but at the same time makes the result easier to reason about and test. The unavailability of some untyped features makes it impossible to write code in a way that represents an Akka anti-pattern and leads to solutions resembling what are considered to be the best practices in normal Akka.

Let's take a look at what these differences look like in practice.