Reason for circular references with classes?
You have a class Company containing a list of Individuals that work for it. Every Individual class instance in the collection contains a reference to the Company they work for.
This way you can easily find out which individuals work for which companies. Note, that it may not necessarily be the best design especially if the classes are persisted into the database using an ORM or a document database.
The most obvious case of circular reference is self-reference: you need it for linked lists, trees, and lots of other recursive structures.
Circular references are often implicit within a hierarchy of relared classes, such as UI elements with arbitrary nesting, or expression trees.
Finally, a common case of circular referencing is bidirectional parent-child relationship: a parent (e.g. a UI panel) holds a reference to an array of its children, and each child (e.g. buttons, tables, etc.) holds a references to the parent. The parent needs to send motifications to its children to tell them that it became enabled, disabled, visible, or invisible; a child may notify the parent of the need to resize, change visual state, etc.
This last example is probably similar to your Creature-CreatureAI pair: they are separate because their concerns are dissimilar, but they have references to each other because they need to cooperate on different tasks.
There any number of reasons for self reference or reference cycles
They may be inherent in the domain model; e.g. people have children who are also people, folders contain other things including other folders. A self reference or cycle is a natural way to implement these things.
They may be inherent to a generic or application specific data structure; e..g. a linked list consists of nodes which include references to the "next" and "previous" node in the list, and this requires the Node class to refer to itself.
The reasoning behind the cyclic reference can be a fundamental part of the design of the application.
Or, it can simply be an implementation convenience, or a historical artefact of previous refactorings or code-base evolution.
Basically, you need to look (holistically) at the application codebase to figure out why these cyclic dependencies exist ... and if they are really necessary.